I am currently trying to label lines that I draw in my Map (in my iOS app, but I guess it applies to all maps).
So what I currently am doing, I simplify my path so that I get rid of most small curves and then just draw my glyphs along that line. Currently that looks like this:
On some parts of the line that's already ok. If the line is quite straight and the corners aren't too spiky.
But in some parts you can just not read anything... So what are strategies to make that look nicer?
Does anybody know an algorithm or a strategy on how to make my path look like the red line here:
I am happy about any ideas on how to improve my drawing :)
I do it, in my commercial map rendering system, by finding a portion of the line without sharp corners. There is no way to make the label look good if it turns corners of a right angle or greater. If there's no section long enough I abbreviate the label (e.g., Link Road becomes Link Rd), or split it on to two lines. If there's still nowhere to draw the label I don't draw it.
Another thing that's important is to adjust the spacing so that ascenders and descenders don't clash, so you need to look at the bounding box of each adjacent pair of letters as you draw the text and add small amounts of space as necessary.
I don't bother to smooth my lines, as you suggest with your red line. It really doesn't seem to matter, at least with street labelling.
I have issue setting up an Openlayers map with vector tiles served from Geoserver. The lines gets screwed up along the edges of the tiles. It looks like the lines are first clipped and then styled instead of the opposite. This makes wide lines look ugly.
Changing the renderBuffer in the OL client doesnt make any difference.
I have similar issues with labels and perhaps the solution is pretty much the same in both cases.
EDIT: The geojson in QGIS shows that there is a buffer around the tiles:
geojson output in QGIS
EDIT 2: I have been doing som more research on the phenomenom and I think both Geoserver and Openlayers are to blame for the artifacts. As seen below, Geoserver does render with a buffer (the pink polygons(1 and 2) contains the black bordered tile extent) but does not include features that lies outside of the tile but inside of the buffer, like the green line(3) in the circle.
That makes the tile rendered with a jack as in the left circle below.
However, even when you have a line in a tile that goes close to the tile border, styled with quite a thick stroke, Openlayers wont render enough of the line outside the tile to make it styled without a jack. Like the right circle below. I have mote obvious examples of that bahviour. This could probably easily be fixed by setting a higher buffer/tolerance value for the tilerendering.
I am using 4-Way floodfill algorithm.
I have a transparent image with black out line.
That is staring point image(without color).
And after filling the color in this image it look like this
Please help me and let me know what can i do for proper fill.
I used and implemented myself FloodFill in other projects and the algorithm goes trough the whole draw, looking for closed spaces and then draw inside (or outside) them.
Your problem happens with every tool in the world that fills a draw, and the problem is the same, the spaces are not 100% closed.
The floodfill algorithm goes pixel by pixel and when it detect a black pixel, it stops. For example, the arm of the scuba driver is not thick enough or it has holes on it, and the flood fill algorithm manages to go trough it and not detect it as an empty space.
Nobody here can tell you why unless we take your project and analyse it, so the best I can offer is a guideline about where your error could be.
I tried the code with an image that has a very precise defined border around it (from here) and it seems to work OK with that image. I suggest perhaps that if you zoom into your image that there is some grey aliasing around the edges which won't get filled. Perhaps the algorithm has a threshold function that can be tweaked?
Try setting the andTolerance value (I tried 4 which seemed to improve my example).
//Call function to flood fill and get new image with filled color
UIImage *image1 = [self.image floodFillFromPoint:tpoint withColor:newcolor andTolerance:4];
I'm writing a script in gimp and I want to place several random points on the screen. I placed in my (python) script the two following lines
gimp.pdb.gimp_context_set_brush_size(5.0)
gimp.pdb.gimp_pencil(drawable,2,p)
But this didn't have the desired effect, or any effect.
Also, I don't know how to set the brush (the small icon next to the brush size in the gui).
Finally, is there a way to get a list of pencil dots on the current layer?
Imagine you are drawing a map of county borders. You are given a set of polygons, one for each boundary, and you draw each polygon.
In places where two counties share a border you just end up drawing the border twice. In the absence of partial transparency effects, and with a solid pen, this is no problem.
But, on maps, borders of this kind are customarily shown by dash-dotted lines. In this case, situations like the one depicted below can happen:
Notice how the dash pattern, which normally is dash-dot-dot, gets screwed up where the two areas share a border. In this case, it happened to become a longdash-dot pattern, but in general it could do anything from coincidentally looking normal to creating a solid line.
How does/should map rendering software prevent artifacts of this kind from occuring?
The artifact is due the fact that the piece of border is drawn twice. Instead of trying to supress such artifacts, you could try to not draw border sections twice, by keeping a list of segments already drawn in memory, and if you encounter a stretch that's already drawn, you don't draw it again.
Your brush pattern colors some pixels black and leaves some pixels alone. Instead of leaving the pixel alone, can you set up your brush pattern to color those pixels white (or whatever your background color is)?
Another possibility is to always draw your county borders twice -- once with a solid white pattern, and again with the brush pattern of your choice.
I suppose they break their border lines into segments, then remove the overlaps.
This is mostly a geometric problem, not a drawing problem.
Instead of going with a dashed line, you could do it Zip-a-tone style, like this:
Zip-a-tone was this graphic art stuff that was basically a sticky sheet of plastic with a regular (printable) pattern of dots on it. To use it, you would lay a big sheet of it over your drawing and cut it around the areas on your drawing that you wanted zip-a-toned, and then peel off the parts you didn't want.
For this image, I just went with an alternating checkerboard pattern, with the lines two pixels wide. Because all the lines are drawn from one big (virtual) block of this checkerboard pattern, you never have to worry about weird artifacts at the joints or any overlap effects.
Angled lines are a bit tricky, but basically you imagine the edges of the line sort of cutting through pixels, and thus you draw them at the appropriate shade of grade instead of full black (in the case of the 45 degree line here, the pixels are drawn with RGB(170, 170, 170), but any angle could be rendered with appropriate shades).
I'm not sure if GDI+ could do this easily using the textured brushes, but maybe. Otherwise you'd have to custom-code it. The advantage of this method over just solid gray lines would be that this would allow some of the background to show through.
This is an interesting question that I never really thought about. I think the only real solution is to render the entire complex figure as a series of lines or paths that do not overlap anywhere. I'm not surprised that GDI+ doesn't handle this situation in any automatic way.