Sensible resolutions - (or patch 5)
Even though the drop small polygons patch does improve mkgmap created maps, there are still really bogus resolutions. take kindergarten polygon (or actually most amenity) which shows up before! primary roads. Light rails (17) that in theory show up before primary roads (only in theory because garmin does not display the railway type before resolution 23, so cutting clutter, but still this is a lot of crap and unused data that the default style puts into the map). There loads of other examples. Certainly landuse like forest is more important on a map like a kindergarten, grave_yard or college and so on. It really seams like, everyone just wanted to see his favourite stuff really early, and by continuing this approach the maps get really overloaded without providing any real information on top. Of course a lot of this has been written when OSM had relatively few information, and showing stuff stupidly early made the map look nice and gave the impression of OSM having lots of data which it had not. Nowadays at least in Western and Central Europe - and especially there where people use mkgmap created maps, there is actually lots of information in OSM and the goal has to be to declutter. That's what this patch does. Adding so many polygons early in a raster map would be somehow okay because it is barely noticeable, and there is no penaly in the time to show it on screen, but on a vector map it is simply not good. On top of the resolutions changes I introduced resolutions 21 and 19 for rendering to have smoother addition of information when zooming. Most of the data is in resolutions 24-22 anyhow (each resolution even if showing the same detail, halves the space needed for including it). Overall I think maps should work out the same size as without this patch (even though there are two resolutions added), but draw much faster on GPS/Mapsource/Qlandkarte GT and give a much better tool for orientation. I don't think adding resolution=23 is good, because it increases map size by more or less 25% (whereas 21 only increases total map size by ~5%, 19 by ~1%) I still left most resolutions 1 step of where I would personally put them, so that in countries with less information the style is still working well. Nevertheless in big cities the map is showing much information too early.
In the Netherlands most of the landuse has been imported, it consists of many very small polygons. The drop small polygons method seems to work very well in drawing the map much faster on the GPS! Negative consequence is that on Mapsource most of the forest disappears too soon, when zooming out. At 5km, with medium details, most of the forests are gone on my map. Can this be controlled in the style file? Like, dont drop small polygons of forests until a certain zoomlevel?
On 02.03.2011 13:53, Marko Mäkelä wrote:
On Wed, Mar 02, 2011 at 01:45:52PM +0100, Minko wrote:
Negative consequence is that on Mapsource most of the forest disappears too soon, when zooming out. How hard would it be to merge nearby polygons on wider zoom levels? It would not work I think. What would be needed is to generalise polygons on lower zoom levels. Meaning merge them together, drop holes, straighten them (well the dp-filter already takes care of that), and have a seperate style-file where there are definitions on what gets merged how. Ideally a hole or scrub part of a forest would be only visible from resolution 24-22 or 24-21 (depending on the size of the whole/scrub). It's the same as you only want to see single houses when zoomed in close, when further away you want to see residential area, and when even further away you want to sea where is urban vs nonurban area. OSM sucks big in this regard and as long raster maps are the primary outcome of OSM data (for lower zooms) then there will be no motivation for change (change which means layering OSM data instead of one big black hole to sink information into). Marko
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 02.03.2011 14:03, schrieb Felix Hartmann:
On 02.03.2011 13:53, Marko Mäkelä wrote:
On Wed, Mar 02, 2011 at 01:45:52PM +0100, Minko wrote:
Negative consequence is that on Mapsource most of the forest disappears too soon, when zooming out. How hard would it be to merge nearby polygons on wider zoom levels? It would not work I think. What would be needed is to generalise polygons on lower zoom levels. Meaning merge them together, drop holes, straighten them (well the dp-filter already takes care of that), and have a seperate style-file where there are definitions on what gets merged how.
In general I think this should be solvable. It will be not an easy task and maybe resource hungry, but I think, this should be possible. The subject was discussed already in January 2010 in a side thread of 'Suggestion - Make Douglas Peucker Algorithm more Configurable'
Ideally a hole or scrub part of a forest would be only visible from resolution 24-22 or 24-21 (depending on the size of the whole/scrub). It's the same as you only want to see single houses when zoomed in close, when further away you want to see residential area, and when even further away you want to sea where is urban vs nonurban area. Yes, this would be nice. OSM sucks big in this regard and as long raster maps are the primary outcome of OSM data (for lower zooms) then there will be no motivation for change (change which means layering OSM data instead of one big black hole to sink information into).
OSM is not a perfect world for cartogaphs. But we have to take it as it is. And it is a database which shows a more or less detailes map at *one* zoom level, the nearest one. I wouldn't like it to include the same information in several zoom levels which have to be held consistent by the users. This will not work. This is a task which *must* be done by algorithms. Regards, Johann
On 02.03.2011 13:45, Minko wrote:
In the Netherlands most of the landuse has been imported, it consists of many very small polygons. The drop small polygons method seems to work very well in drawing the map much faster on the GPS! Negative consequence is that on Mapsource most of the forest disappears too soon, when zooming out. At 5km, with medium details, most of the forests are gone on my map. Can this be controlled in the style file? Like, dont drop small polygons of forests until a certain zoomlevel? No, and this is a principal OSM problem. OSM is basically the only existing map database, that has no different detail for different resolutions. This works well when zoomed close in, or for raster maps it just increases computing time (at some point the hole is smaller than 1 pixel). However any normal database would have a different approach that has a detailed forest for high resolutions, and the lower the resolutions the more detail gets dropped in the data itself. So holes of a forest would dispappear.
The solution would be to have forest relations for lower zoom levels. So like from mkgmap resolution 21 and down - only show relation polygons or very big polygons. In the end this change just shows how crappy dutch data imports actually are for a vector map database. In most places even a setting of 15 (forest would disappear one resolution earlier - which would be 3km) works fine.
Could this patch be included? I really think maps in Western Europe (where most mkgmap users are) look much better on a) old GPS like etrex b) street units like Nuvi 255W or c) Mapsource/Basecamp/Qlandkarte GT. About 2 month ago the resolutions for POI got lowered to sensible defaults (they were also way off, but on GPS this usually wouldn't get noticed as they simply did not shown them) - polygons and streets (very slight changes) should follow. All answers below were about r. 1893 and Dutch problems with another commit but nothing to do with this patch. On 02.03.2011 13:20, Felix Hartmann wrote:
Even though the drop small polygons patch does improve mkgmap created maps, there are still really bogus resolutions.
take kindergarten polygon (or actually most amenity) which shows up before! primary roads. Light rails (17) that in theory show up before primary roads (only in theory because garmin does not display the railway type before resolution 23, so cutting clutter, but still this is a lot of crap and unused data that the default style puts into the map). There loads of other examples.
Certainly landuse like forest is more important on a map like a kindergarten, grave_yard or college and so on. It really seams like, everyone just wanted to see his favourite stuff really early, and by continuing this approach the maps get really overloaded without providing any real information on top. Of course a lot of this has been written when OSM had relatively few information, and showing stuff stupidly early made the map look nice and gave the impression of OSM having lots of data which it had not. Nowadays at least in Western and Central Europe - and especially there where people use mkgmap created maps, there is actually lots of information in OSM and the goal has to be to declutter. That's what this patch does. Adding so many polygons early in a raster map would be somehow okay because it is barely noticeable, and there is no penaly in the time to show it on screen, but on a vector map it is simply not good.
On top of the resolutions changes I introduced resolutions 21 and 19 for rendering to have smoother addition of information when zooming. Most of the data is in resolutions 24-22 anyhow (each resolution even if showing the same detail, halves the space needed for including it). Overall I think maps should work out the same size as without this patch (even though there are two resolutions added), but draw much faster on GPS/Mapsource/Qlandkarte GT and give a much better tool for orientation. I don't think adding resolution=23 is good, because it increases map size by more or less 25% (whereas 21 only increases total map size by ~5%, 19 by ~1%)
I still left most resolutions 1 step of where I would personally put them, so that in countries with less information the style is still working well. Nevertheless in big cities the map is showing much information too early.
On Wed, Mar 09, 2011 at 11:34:30PM +0100, Felix Hartmann wrote:
Could this patch be included?
I really think maps in Western Europe (where most mkgmap users are) look much better on a) old GPS like etrex b) street units like Nuvi 255W or c) Mapsource/Basecamp/Qlandkarte GT. About 2 month ago the resolutions for POI got lowered to sensible defaults (they were also way off, but on GPS this usually wouldn't get noticed as they simply did not shown them) - polygons and streets (very slight changes) should follow.
Sorry, I am currently busy with work and other duties, until next week at least. If I remember correctly, your patch would lower the visibility of motorways as well. What would become visible first when zooming in from the widest possible level? Only sea polygons? Marko
On 10.03.2011 12:18, Marko Mäkelä wrote:
On Wed, Mar 09, 2011 at 11:34:30PM +0100, Felix Hartmann wrote:
Could this patch be included?
I really think maps in Western Europe (where most mkgmap users are) look much better on a) old GPS like etrex b) street units like Nuvi 255W or c) Mapsource/Basecamp/Qlandkarte GT. About 2 month ago the resolutions for POI got lowered to sensible defaults (they were also way off, but on GPS this usually wouldn't get noticed as they simply did not shown them) - polygons and streets (very slight changes) should follow. Sorry, I am currently busy with work and other duties, until next week at least.
If I remember correctly, your patch would lower the visibility of motorways as well. What would become visible first when zooming in from the widest possible level? Only sea polygons? Nope, motorways stay (at least if the default resolutions are used. By default no resolution 14 is created. But compiling Europe at 14 with motorways looks crap. Been there, done that. If you decide to add resolution 14 into the build, then yes motorways are not visible and only sea and big cities -- in reality we would want to have a seperate overview map for resolutions 14&16 that is only shown in Mapsource/Qlandkarte GT, as on all GPS for resolution 14 and 16 the basemap is the better match (a lot quicker to pan) for resolution 14 and 16).
What I did really lower are motorway links to 18. They are not really visible (too small) in resolution 16 anyhow, and slow down the GPS. Also at such a resolution you never actually drive in your car, 16 is basically only for getting an overview on a country basis - hence motorway links are not needed). I did not change motorway junctions, that indeed might be handy at low resolutions (though basically at resolution 16 you don't need detailed junction layout, as in nearly all cases to motorways crossing there are junctions close to the crossing).
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, Finally I got time for this patch. The gmapsupp.img for Finland has grown a lot, and much of it is probably due to Corine landuse imports. I hope that this patch will scratch that itch too. :-) Now Finland is finally liberated from unclosed polygons, too. I even got address search working again on the Edge (without --index), by replacing --charset=latin1 with --code-page=1252.
Nope, motorways stay (at least if the default resolutions are used. By default no resolution 14 is created. But compiling Europe at 14 with motorways looks crap. Been there, done that.
Right, there should be some method of simplifying and merging polygons in the lowest resolution levels. Until we are there, it is probably best to drop the polygons from the widest zooms. A good use case of merging polygons would be the huge lake areas in Finland. If you look close, the lakes are small and scattered. From bigger distance, it could be approximated with one huge lake. But, currently the map does not show any lakes when zooming out. One thing that I do not understand in your patch is this: < --- styles/default/options (revision 1902) < +++ styles/default/options (working copy) < @@ -17,7 +17,7 @@ < < # The levels specification for this style < # < -levels = 0:24, 1:22, 2:20, 3:18, 4:16 < +levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18, 6:16 Is the "resolution" a mkgmap-only entity, which is mapped to zoom layers known as "levels" in the IMG file? If that is the case, wouldn't this change introduce two more zoom layers to the map, potentially growing the file size? Regarding railways, you are lowering them to resolution 22, with one exception: railway=subway&!(tunnel=yes) is resolution 21. I guess that it is a typo and you meant 22. I think that this lowering is OK, because Garmin would not show railways when zooming out from 500m, even in the highest map detail level. They must really hate railways, I guess. Best regards, Marko
On 25.03.2011 08:42, Marko Mäkelä wrote:
Hi Felix,
Finally I got time for this patch. The gmapsupp.img for Finland has grown a lot, and much of it is probably due to Corine landuse imports. I hope that this patch will scratch that itch too. :-) Now Finland is finally liberated from unclosed polygons, too. I even got address search working again on the Edge (without --index), by replacing --charset=latin1 with --code-page=1252.
Nope, motorways stay (at least if the default resolutions are used. By default no resolution 14 is created. But compiling Europe at 14 with motorways looks crap. Been there, done that.
Right, there should be some method of simplifying and merging polygons in the lowest resolution levels. Until we are there, it is probably best to drop the polygons from the widest zooms. A good use case of merging polygons would be the huge lake areas in Finland. If you look close, the lakes are small and scattered. From bigger distance, it could be approximated with one huge lake. But, currently the map does not show any lakes when zooming out.
One thing that I do not understand in your patch is this:
< --- styles/default/options (revision 1902) < +++ styles/default/options (working copy) < @@ -17,7 +17,7 @@ < < # The levels specification for this style < # < -levels = 0:24, 1:22, 2:20, 3:18, 4:16 < +levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18, 6:16
Is the "resolution" a mkgmap-only entity, which is mapped to zoom layers known as "levels" in the IMG file? If that is the case, wouldn't this change introduce two more zoom layers to the map, potentially growing the file size? Yes, but there is not a lot of information in those zoom levels anyhow. Overall I would say with the patch applied (on my tests) the gmapsupp.img filesize stays the same. But the GPS renders it much faster. The additional levels of 19 and 21 really help to make the zooming in much much smoother and the GPS can render the map faster. Quite a few people even use resolution 23 as intermediary, but I left that out, because 23 would increase overall gmapsupp.img size by 20-25% (whereas increases 21 by 3-4%, 19 is a change of under 1%)
Regarding railways, you are lowering them to resolution 22, with one exception: railway=subway&!(tunnel=yes) is resolution 21. I guess that it is a typo and you meant 22. I think that this lowering is OK, because Garmin would not show railways when zooming out from 500m, even in the highest map detail level. They must really hate railways, I guess.
Yes - that's a typo. But as long as we inside OSM have no real mean of identifying the main railway lines the railways should not be shown as early anyhow.
Best regards,
Marko
On Fri, Mar 25, 2011 at 09:16:27AM +0100, Felix Hartmann wrote:
Is the "resolution" a mkgmap-only entity, which is mapped to zoom layers known as "levels" in the IMG file? If that is the case, wouldn't this change introduce two more zoom layers to the map, potentially growing the file size? Yes, but there is not a lot of information in those zoom levels anyhow. Overall I would say with the patch applied (on my tests) the gmapsupp.img filesize stays the same. But the GPS renders it much faster. The additional levels of 19 and 21 really help to make the zooming in much much smoother and the GPS can render the map faster.
I have tweaked your patch a little and will try to experiment futher. I already noticed that the Edge 705 draws the polygons much quicker with the highest detail. I did not test adding the levels 19 and 21 yet. I don't like having primary,secondary,tertiary at the same resolution (20). I'll see what happens if I lower tertiary and secondary_link to resolution 21.
Yes - that's a typo. But as long as we inside OSM have no real mean of identifying the main railway lines the railways should not be shown as early anyhow.
As we know, the Garmin firmware wants to hide railways when zooming out (on the Edge 705, further than 80m at the lowest detail level, further than 500m at the highest level). Because of this, this kind of translation of major/minor railways would would require a custom polyline code and a TYP file. Maybe that code should even be routable, so that one can get a nice map display when travelling by train. I have sometimes amused myself by using straight-line routing and watching the progress of the estimated time of arrival. Actually, we do have a mean: if there are multiple parallel tracks (each drawn as a separate way with railway=*), it is a major railway. It should be doable to merge adjacent ways at lower resolutions and sum the "weights" of the ways, to decide what to draw. A style file extension could be useful, to specify e.g., the following: * draw individual railways at resolution 24 * merge parallel tracks to one and draw them at resolution 22..23 * merge parallel tracks to one and draw if count>1 at resolution 21 * merge parallel tracks to one and draw if count>3 at resolution 20 For polygons, it could be useful to specify the minimum size that qualifies for inclusion in a given resolution. Of course, small adjacent polygons would have to be merged together first. I am beginning to think that it could be useful to have low-resolution versions of the OpenStreetMap data, generated by an experimental algorithm that attempts to merge polygons and lines as suggested above. If it is not too CPU intensive to merge adjacent areas and lines, perhaps it could be implemented inside mkgmap after all. Best regards, Marko
On 25.03.2011 16:45, Marko Mäkelä wrote:
On Fri, Mar 25, 2011 at 09:16:27AM +0100, Felix Hartmann wrote:
Is the "resolution" a mkgmap-only entity, which is mapped to zoom layers known as "levels" in the IMG file? If that is the case, wouldn't this change introduce two more zoom layers to the map, potentially growing the file size? Yes, but there is not a lot of information in those zoom levels anyhow. Overall I would say with the patch applied (on my tests) the gmapsupp.img filesize stays the same. But the GPS renders it much faster. The additional levels of 19 and 21 really help to make the zooming in much much smoother and the GPS can render the map faster.
I have tweaked your patch a little and will try to experiment futher. I already noticed that the Edge 705 draws the polygons much quicker with the highest detail. I did not test adding the levels 19 and 21 yet.
I don't like having primary,secondary,tertiary at the same resolution (20). I'll see what happens if I lower tertiary and secondary_link to resolution 21. you may lower secondary_link and tertiary_link to resolution 21, but I would not lower tertiary to 21. It is best at 20 as otherwise incomplete "networks" happen. In my own styles I draw all primaries or secondaries with and int_ref even one resolution earlier, problem is that loads of int_ref are missing for primaries. If they were complete than this would be a good mean to separate important primaries from less important ones. Anyhow primary is resolution 19, primary link to tertiary link 20.
The main part of the patch for me is anyhow the polygons part. The highways file apart from the railways that are plain stupid at the resolution given, are no really big changes. (well things like highway=* & motorroad=yes should obviously not be at resolution 16 if it is neither trunk/motorway, often such roads are inside cities or not so important at all, so 18 is already early - one could even move it to 19)
Yes - that's a typo. But as long as we inside OSM have no real mean of identifying the main railway lines the railways should not be shown as early anyhow.
As we know, the Garmin firmware wants to hide railways when zooming out (on the Edge 705, further than 80m at the lowest detail level, further than 500m at the highest level). Because of this, this kind of translation of major/minor railways would would require a custom polyline code and a TYP file. Maybe that code should even be routable, so that one can get a nice map display when travelling by train. I have sometimes amused myself by using straight-line routing and watching the progress of the estimated time of arrival.
Actually, we do have a mean: if there are multiple parallel tracks (each drawn as a separate way with railway=*), it is a major railway. It should be doable to merge adjacent ways at lower resolutions and sum the "weights" of the ways, to decide what to draw. A style file extension could be useful, to specify e.g., the following:
* draw individual railways at resolution 24 * merge parallel tracks to one and draw them at resolution 22..23 * merge parallel tracks to one and draw if count>1 at resolution 21 * merge parallel tracks to one and draw if count>3 at resolution 20
For polygons, it could be useful to specify the minimum size that qualifies for inclusion in a given resolution. Of course, small adjacent polygons would have to be merged together first.
We already have that currently set to 8. But 8 is still tiny and patchy. The only real solution is joining of polygons and then one could show some polygons earlier again. Merging parallel lines would be another major thing. Take all motorroads - before resolution 20 one rarely notices the different directions. They should be joined by relations in OSM data already except for cases where one would like to sea both directions early (huge differences on where they are).
I am beginning to think that it could be useful to have low-resolution versions of the OpenStreetMap data, generated by an experimental algorithm that attempts to merge polygons and lines as suggested above. If it is not too CPU intensive to merge adjacent areas and lines, perhaps it could be implemented inside mkgmap after all.
Best regards,
Marko
On Fri, Mar 25, 2011 at 05:09:19PM +0100, Felix Hartmann wrote:
I did not test adding the levels 19 and 21 yet.
Bad news: Adding just one level would blow up some limit. My largest tile .img is about 20 megabytes. Time to split my tiles again, I guess.
you may lower secondary_link and tertiary_link to resolution 21, but I would not lower tertiary to 21. It is best at 20 as otherwise incomplete "networks" happen.
Well, broken networks are a matter of fact for bicycling already. In bicycling, I favor highway=residential and highway=path, and they won't be visible at useful zoom levels. But I got your point; I will only lower the links. I guess I could lower primary_link and trunk_link too. The link roads are not that long anyway. Marko
On Fri, Mar 25, 2011 at 07:11:05PM +0200, Marko Mäkelä wrote:
I did not test adding the levels 19 and 21 yet.
Bad news: Adding just one level would blow up some limit. My largest tile .img is about 20 megabytes. Time to split my tiles again, I guess.
More bad news: After the additional splitting, my gmapsupp.img grew to 94 MB. Without the added levels and the splitting, it would be about 80 MB. The baseline (without the patch and splitting), it would be about 82 MB. I think that the growth is unacceptable. My revised patch is attached, including the changes to the options, which I am reluctant to apply. If you have no objections, I would like to commit the changes to polygons and lines. Best regards, Marko
On 25.03.2011 22:01, Marko Mäkelä wrote:
On Fri, Mar 25, 2011 at 07:11:05PM +0200, Marko Mäkelä wrote:
I did not test adding the levels 19 and 21 yet.
Bad news: Adding just one level would blow up some limit. My largest tile .img is about 20 megabytes. Time to split my tiles again, I guess.
More bad news: After the additional splitting, my gmapsupp.img grew to 94 MB. Without the added levels and the splitting, it would be about 80 MB. The baseline (without the patch and splitting), it would be about 82 MB. I think that the growth is unacceptable.
My revised patch is attached, including the changes to the options, which I am reluctant to apply. If you have no objections, I would like to commit the changes to polygons and lines. Well then add a note to the options file, that while it is nicer and faster on the GPS to draw (if level 21 and 19 are included) - however it adds up 15% to filesize of gmapsupp.img (though I don't get how you get 15% when I get around 5% - well that's with exporting from Mapsource where the mdr file takes up quite a lot of space too). What is your commandline options?
Also I don't really sea why healthcare polygons should be visible already at resolution 22. I think 23 (so 24 for everyone who does not use 23) is enough. Essentially it's no more important than plain houses in my opinion. Besides - all my resolutions were the bare minimum change that I thought is needed (and that was before the drop small polygons patch got commited, which made a huge change too when used with default style-file). highway=service at 23 is another thing I'm not too happy. Often highway=service connect residential roads and tracks. That's why I put them to 22. Maybe a finer seperation would be needed using service=* tag.
Best regards,
Marko
On Sat, Mar 26, 2011 at 02:06:11AM +0100, Felix Hartmann wrote:
Well then add a note to the options file, that while it is nicer and faster on the GPS to draw (if level 21 and 19 are included) - however it adds up 15% to filesize of gmapsupp.img (though I don't get how you get 15% when I get around 5% - well that's with exporting from Mapsource where the mdr file takes up quite a lot of space too).
One thing that I did not measure was the impact of the additional tile splitting, without changes to the options.
What is your commandline options?
Pretty basic, see http://www.polkupyoraily.net/osm/files/mkgmap.args (this is the version before the additional splitting).
Also I don't really sea why healthcare polygons should be visible already at resolution 22. I think 23 (so 24 for everyone who does not use 23) is enough. Essentially it's no more important than plain houses in my opinion.
I was trying to be consistent with amenity=hospital, but I guess we could lower amenity=hospital to 23 as well. Hmm, there is no amenity=doctors in the polygons file. I will add that too.
highway=service at 23 is another thing I'm not too happy. Often highway=service connect residential roads and tracks.
I haven't seen that around here. The highway=service are usually driveways and parking aisles, not for passing through (at least not by motor vehicles).
That's why I put them to 22. Maybe a finer seperation would be needed using service=* tag.
What would you suggest? Do you agree that service=parking_aisle should be 23 or 24? What about service=alley and service=driveway? I have drawn lots of tiny service=driveway that connect properties to a highway=residential or highway=tertiary and intersect with a cycle/footway. It would seem awkward if service=alley were visible before service=driveway or service=parking_aisle, because alleys are even more minor. Marko
On 26.03.2011 08:12, Marko Mäkelä wrote:
On Sat, Mar 26, 2011 at 02:06:11AM +0100, Felix Hartmann wrote:
Well then add a note to the options file, that while it is nicer and faster on the GPS to draw (if level 21 and 19 are included) - however it adds up 15% to filesize of gmapsupp.img (though I don't get how you get 15% when I get around 5% - well that's with exporting from Mapsource where the mdr file takes up quite a lot of space too).
One thing that I did not measure was the impact of the additional tile splitting, without changes to the options.
What is your commandline options?
Pretty basic, see http://www.polkupyoraily.net/osm/files/mkgmap.args (this is the version before the additional splitting).
Also I don't really sea why healthcare polygons should be visible already at resolution 22. I think 23 (so 24 for everyone who does not use 23) is enough. Essentially it's no more important than plain houses in my opinion.
I was trying to be consistent with amenity=hospital, but I guess we could lower amenity=hospital to 23 as well. Hmm, there is no amenity=doctors in the polygons file. I will add that too. Well, for what I noticed on actual usage is that doctors, hospitals and dentist get tagged themselves. All other stuff e.g. especiall care related like chiropody or similar stuff you would not find on a general purpose map, gets thrown into healthcare. Therefore I would show amenity=hospital & ( amenity=healthcare & healthcare=hospital ) at resolution 22, include amenity=docotors at 23 and add healthcare to 23 (if not 24). The reasoning has to go that important stuff is shown early. While a central train station is shown early, tram stations are showing up later...
highway=service at 23 is another thing I'm not too happy. Often highway=service connect residential roads and tracks.
I haven't seen that around here. The highway=service are usually driveways and parking aisles, not for passing through (at least not by motor vehicles).
That's why I put them to 22. Maybe a finer seperation would be needed using service=* tag.
What would you suggest? Do you agree that service=parking_aisle should be 23 or 24? What about service=alley and service=driveway? I have drawn lots of tiny service=driveway that connect properties to a highway=residential or highway=tertiary and intersect with a cycle/footway. It would seem awkward if service=alley were visible before service=driveway or service=parking_aisle, because alleys are even more minor. yeah, that is okay on the final patch.
Marko
On Sat, Mar 26, 2011 at 11:51:46AM +0100, Felix Hartmann wrote:
I was trying to be consistent with amenity=hospital, but I guess we could lower amenity=hospital to 23 as well. Hmm, there is no amenity=doctors in the polygons file. I will add that too. Well, for what I noticed on actual usage is that doctors, hospitals and dentist get tagged themselves. All other stuff e.g. especiall care related like chiropody or similar stuff you would not find on a general purpose map, gets thrown into healthcare. Therefore I would show amenity=hospital & ( amenity=healthcare & healthcare=hospital ) at resolution 22, include amenity=docotors at 23 and add healthcare to 23 (if not 24). The reasoning has to go that important stuff is shown early. While a central train station is shown early, tram stations are showing up later...
OK, that makes sense. Let me make healthcare=hospital and amenity=hospital resolution 22 and the other healthcare tags 23. Marko
On Sat, Mar 26, 2011 at 02:06:11AM +0100, Felix Hartmann wrote:
Maybe a finer seperation would be needed using service=* tag.
I was not aware of the service=drive-through tag, which is documented at http://wiki.openstreetmap.org/wiki/Key:service I would suggest something like this: highway=service & service=parking_aisle [0x07 road_class=0 road_speed=1 resolution 24] highway=service & (service=alley|service=driveway) [0x07 road_class=0 road_speed=0 resolution 23] highway=service [0x07 road_class=0 road_speed=2 resolution 22] This would make highway=service with unknown or missing service=* visible before parking_aisle, driveway and alley. Marko
Hi Felix,
More bad news: After the additional splitting, my gmapsupp.img grew to 94 MB. Without the added levels and the splitting, it would be about 80 MB. The baseline (without the patch and splitting), it would be about 82 MB. I think that the growth is unacceptable.
I accidentally generated the extra-split map with today's data, using the patch for lines and polygons (but not options). The resulting gmapsupp.img is 83 MB. Without the extra splitting, it was 80 MB yesterday. If we assume that the map has not changed much between yesterday and today, the two extra levels would cost 11 MB, or more than 10%. If we include the "collateral damage" of additional splitting, it really is 14 MB, or 18% additional file size. Would you approve the attached patch? Marko
Marko Mäkelä <marko.makela@iki.fi> writes:
Actually, we do have a mean: if there are multiple parallel tracks (each drawn as a separate way with railway=*), it is a major railway. It should be doable to merge adjacent ways at lower resolutions and sum the "weights" of the ways, to decide what to draw. A style file extension could be useful, to specify e.g., the following:
* draw individual railways at resolution 24 * merge parallel tracks to one and draw them at resolution 22..23 * merge parallel tracks to one and draw if count>1 at resolution 21 * merge parallel tracks to one and draw if count>3 at resolution 20
I don't think that works. Around me, there are many railroads that are single-track but go long distances. The 1950s or so USGS 1:250K topo maps are interesting; railroads are thick black lines, since they used to be very important. The right test is probably: do any long-distance routes use this way? But really we just need to tag through railroads vs yards and sidings, and have some way to combine double-track railroads at smaller scales.
Actually, we do have a mean: if there are multiple parallel tracks (each
drawn as a separate way with railway=*), it is a major railway. It should be doable to merge adjacent ways at lower resolutions and sum the "weights" of the ways, to decide what to draw. A style file extension could be useful, to specify e.g., the following:
* draw individual railways at resolution 24 * merge parallel tracks to one and draw them at resolution 22..23 * merge parallel tracks to one and draw if count>1 at resolution 21 * merge parallel tracks to one and draw if count>3 at resolution 20
For polygons, it could be useful to specify the minimum size that qualifies for inclusion in a given resolution. Of course, small adjacent polygons would have to be merged together first.
I am beginning to think that it could be useful to have low-resolution versions of the OpenStreetMap data, generated by an experimental algorithm that attempts to merge polygons and lines as suggested above. If it is not too CPU intensive to merge adjacent areas and lines, perhaps it could be implemented inside mkgmap after all.
I'm thinking since some time about an algorithm for merging small polygons. Up to now I have not found an suitable algorithm. In another case I have thought about merging parallel lines, especially the both tracks of highways. While reading your mail I got the insight, that this are possibly two similar problems. In both cases there should be two objects with a small space between it be replaced by a merged single one. The algorithm in general would be: - Increase all polygons/lines with a outline. - Check all increased polygons, if some of them overlap. - If so, merge the original version of them. But I expect this to be a really resource hungry task. Regards, Johann.
On 26/03/2011 15:50, Johann Gail wrote:
Actually, we do have a mean: if there are multiple parallel tracks (each
drawn as a separate way with railway=*), it is a major railway. It should be doable to merge adjacent ways at lower resolutions and sum the "weights" of the ways, to decide what to draw. A style file extension could be useful, to specify e.g., the following:
* draw individual railways at resolution 24 * merge parallel tracks to one and draw them at resolution 22..23 * merge parallel tracks to one and draw if count>1 at resolution 21 * merge parallel tracks to one and draw if count>3 at resolution 20
For polygons, it could be useful to specify the minimum size that qualifies for inclusion in a given resolution. Of course, small adjacent polygons would have to be merged together first.
I am beginning to think that it could be useful to have low-resolution versions of the OpenStreetMap data, generated by an experimental algorithm that attempts to merge polygons and lines as suggested above. If it is not too CPU intensive to merge adjacent areas and lines, perhaps it could be implemented inside mkgmap after all.
I'm thinking since some time about an algorithm for merging small polygons. Up to now I have not found an suitable algorithm. In another case I have thought about merging parallel lines, especially the both tracks of highways. While reading your mail I got the insight, that this are possibly two similar problems. In both cases there should be two objects with a small space between it be replaced by a merged single one.
The algorithm in general would be: - Increase all polygons/lines with a outline. - Check all increased polygons, if some of them overlap. - If so, merge the original version of them.
But I expect this to be a really resource hungry task.
Regards, Johann.
I thought the --merge-lines option did part of what you're saying? i.e. merge lines at low zoom levels. If it doesn't do that, then what does --merge-lines do? -- Charlie
On 26.03.2011 13:11, Charlie Ferrero wrote:
On 26/03/2011 15:50, Johann Gail wrote:
Actually, we do have a mean: if there are multiple parallel tracks (each
drawn as a separate way with railway=*), it is a major railway. It should be doable to merge adjacent ways at lower resolutions and sum the "weights" of the ways, to decide what to draw. A style file extension could be useful, to specify e.g., the following:
* draw individual railways at resolution 24 * merge parallel tracks to one and draw them at resolution 22..23 * merge parallel tracks to one and draw if count>1 at resolution 21 * merge parallel tracks to one and draw if count>3 at resolution 20
For polygons, it could be useful to specify the minimum size that qualifies for inclusion in a given resolution. Of course, small adjacent polygons would have to be merged together first.
I am beginning to think that it could be useful to have low-resolution versions of the OpenStreetMap data, generated by an experimental algorithm that attempts to merge polygons and lines as suggested above. If it is not too CPU intensive to merge adjacent areas and lines, perhaps it could be implemented inside mkgmap after all.
I'm thinking since some time about an algorithm for merging small polygons. Up to now I have not found an suitable algorithm. In another case I have thought about merging parallel lines, especially the both tracks of highways. While reading your mail I got the insight, that this are possibly two similar problems. In both cases there should be two objects with a small space between it be replaced by a merged single one.
The algorithm in general would be: - Increase all polygons/lines with a outline. - Check all increased polygons, if some of them overlap. - If so, merge the original version of them.
But I expect this to be a really resource hungry task.
Regards, Johann.
I thought the --merge-lines option did part of what you're saying? i.e. merge lines at low zoom levels. If it doesn't do that, then what does --merge-lines do?
it merges a single street consisting of several parts (behind not beside each other) into one street if name is equal (more or less).
participants (6)
-
Charlie Ferrero -
Felix Hartmann -
Greg Troxel -
Johann Gail -
Marko Mäkelä -
Minko