[mkgmap-dev] {Spam?} multipolygon with outer polygon within inner polygons
Hi, I'm trying to build a map of The Netherlands and got some problems with rendering the administrative borders correctly. Some parts were related to broken relations between tiles, but the major one was caused by a complex relation of enclaves/exclaves of Baarle in the south of the country. I examined this area more closely and narrowed the problem down to this situation, where I cant render the map correctly with mkgmap: A = one big outer ring (the Dutch municipality of Baarle-Nassau), B1, B2 = some islands inside (Belgium territory, role=inner) C= Within some of those islands there are polygons (Dutch, role=outer) It goes wrong with those outer polygons within the inner polygons. Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg The relation can be found at http://betaplace.emaitie.de/webapps.rel onId=47798 There are no gaps or faults within the relation as far as I can see. I put this question and a few examples of my map also on the forum at http://forum.openstreetmap.org/viewtopic.php?pid=59370 Thanks, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Maps crashing Mapsource in big cities
To me it seems that either we do something wrong, or Mapsource cannot handle very detailed places. Try compiling Australia from Geofabrik (I used maxnodes=130 - so smaller than default 16...) with the following commandline: start /low /b /wait java -enableassertions -jar -Xmx4200M mkgmap.jar --max-jobs=2 --reduce-point-density=5.4 --reduce-point-density-polygon=4 --suppress-dead-end-nodes --index --delete-tags-file=deletetags --blacklist-tags-file=deletetags --adjust-turn-headings --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 --location-autofill=1 --description=openmtbmap_%abr%_%date% --route --country-abbr=%abr% --country-name=%country% --mapname=%mapid% --family-id=%mapid% --product-id=1 --series-name=openmtbmap_%abr%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapset --area-name=%country% d:\garmin\mkgmap_680\maps\%mapid%00%tile%.osm.gz At the latest on resolution=24 it crashes. If I use --generate-sea=no-mp;extend then it already crashes on resolution 22 (zoomlevel 700m). Simply center onto the city POI of Melbourne and zoom in. Same problem exists for Greece and Athens. (it's not related to the TYPfile - Mapsource also crashes without registered typfile). Reports I got indicate that the maps not only crash Mapsource but also BSOD Garmin GPS (though no damage done, except restart needed). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] heed the through_route relation when adjusting turn headings
Hi Clinton, On Sat, Feb 6, 2010 at 7:43 PM, Mark Burton ma...@ordern.com wrote: This new relation (type through_route) specifies which 2 ways are the through route at a junction. I have been testing this patch too, and have so far not found any problems. Is through route documented in the OSM Wiki? I was unable to find any information on this. Not yet, but it should be. I was rather hoping that some kind person would add a page to the Wiki describing it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Hello Felix, To me it seems that either we do something wrong, or Mapsource cannot handle very detailed places. Try compiling Australia from Geofabrik (I used maxnodes=130 - so smaller than default 16...) with the following commandline: start /low /b /wait java -enableassertions -jar -Xmx4200M mkgmap.jar --max-jobs=2 --reduce-point-density=5.4 --reduce-point-density-polygon=4 --suppress-dead-end-nodes --index --delete-tags-file=deletetags --blacklist-tags-file=deletetags --adjust-turn-headings --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 --location-autofill=1 --description=openmtbmap_%abr%_%date% --route --country-abbr=%abr% --country-name=%country% --mapname=%mapid% --family-id=%mapid% --product-id=1 --series-name=openmtbmap_%abr%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapset --area-name=%country% d:\garmin\mkgmap_680\maps\%mapid%00%tile%.osm.gz At the latest on resolution=24 it crashes. If I use --generate-sea=no-mp;extend then it already crashes on resolution 22 (zoomlevel 700m). Simply center onto the city POI of Melbourne and zoom in. Same problem exists for Greece and Athens. (it's not related to the TYPfile - Mapsource also crashes without registered typfile). Reports I got indicate that the maps not only crash Mapsource but also BSOD Garmin GPS (though no damage done, except restart needed). Could it be simply that the map has too much stuff in it and some limit in mapsource/gps is being exceeded. What happens if you use smaller tiles? Do the same problems occur? I don't understand why people make such big tiles, what's the benefit? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Mark Burton escribió: I don't understand why people make such big tiles, what's the benefit? I use as big tiles as I can to avoid inter tile routing problems. Is it justified? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Wrong multipolygon warnings
Compiling Spain I get several warnings similar to the one below, that point to data that are correct (or it seems to me). 2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/319017 contains errors. 2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427391078[5P : (44132028[5P]) carries role inner but is not inside any outer polygon. Potentially it does not belong to this multipolygon. Reported way (hole in the building) lacks in the resulting map. Is it a know bug? Another question, why are polygons so deformed in MapSource compared to Mapnik? inline: Pantallazo-1.jpeginline: Pantallazo-2.jpeg___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
Those borderlines form part of different type of administration regions, (countries, provinces, municipalities etc). My question is not to understand why they are tagged like that, but how to make them render them well into mapsource. Is there some kind of patch I can try out, and where/how can I apply it? Im new regarding patching mkgmap, just using the latest release. Chris wrote: Hi, what I don't understand: Why is the complex MP processing for borders necessary while we are (mostly) only interested in the border _lines_ ? Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Carlos Dávila wrote: Mark Burton escribió: I don't understand why people make such big tiles, what's the benefit? I use as big tiles as I can to avoid inter tile routing problems. Is it justified? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev The same problem about crashing MapSource and RoadTrip has also been reported for my maps (e.g. eastern Australia, north and south of Brisbane). The mapbuilding script tries to make those maps as large as possible. Perhaps related is that I upped the max-nodes from 1.400.000 to 1.600.000 for the current map version. I'll reduce the max-nodes for the next update but, ideally, Mkgmap should complain and quit if there is too much information in the source data (This is certainly no complaint, ofcourse I know this all depends on the understanding of the Garmin format). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
CD I use as big tiles as I can to avoid inter tile routing problems. Is CD it justified? Currently yes, there is some justification in doing that. The splitter doesn't currently handle all cases at the edge of tiles correctly, so in that sense it's a case of the fewer tile edges the better so the impact of this is minimised. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Hello Lambertus, The same problem about crashing MapSource and RoadTrip has also been reported for my maps (e.g. eastern Australia, north and south of Brisbane). The mapbuilding script tries to make those maps as large as possible. Perhaps related is that I upped the max-nodes from 1.400.000 to 1.600.000 for the current map version. I'll reduce the max-nodes for the next update but, ideally, Mkgmap should complain and quit if there is too much information in the source data (This is certainly no complaint, ofcourse I know this all depends on the understanding of the Garmin format). OK - you tell us what the limit is and we'll make sure that mkgmap gripes if you bust the limit. Seriously, if you can provide any info as what works and what doesn't in terms of maps sizes, numbers of lines, polys, nodes, etc. that would be useful and we can code accordingly. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
CD I use as big tiles as I can to avoid inter tile routing problems. Is CD it justified? Currently yes, there is some justification in doing that. The splitter doesn't currently handle all cases at the edge of tiles correctly, so in that sense it's a case of the fewer tile edges the better so the impact of this is minimised. Not sure what Chris is referring to there. I am aware of 2 issues related to inter-tile routing: 1 - the inability of mapsource to route across more than 1 tile boundary. 2 - the problem where a route needs to go from one tile to another and then back to the original tile (this could be related to problem 1). Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
On 12.02.2010 15:15, Mark Burton wrote: Hello Lambertus, The same problem about crashing MapSource and RoadTrip has also been reported for my maps (e.g. eastern Australia, north and south of Brisbane). The mapbuilding script tries to make those maps as large as possible. Perhaps related is that I upped the max-nodes from 1.400.000 to 1.600.000 for the current map version. I'll reduce the max-nodes for the next update but, ideally, Mkgmap should complain and quit if there is too much information in the source data (This is certainly no complaint, ofcourse I know this all depends on the understanding of the Garmin format). OK - you tell us what the limit is and we'll make sure that mkgmap gripes if you bust the limit. Seriously, if you can provide any info as what works and what doesn't in terms of maps sizes, numbers of lines, polys, nodes, etc. that would be useful and we can code accordingly. The problem seems to me, that if a tile has more max-nodes, then a very dense city (like Athens, Melbourne, ...) in an otherwise rather empty area (huge tile) will crash. For Athens I had to go as low as 600.000, for Melbourne 800.000 was fine. 1.600.000 is definitely not only crashing a few tiles, but in my eyes around 10% of European tiles. A solution to use bigger max-nodes would be if resolution=23 were usable. Currently the rounding goes havoc if you use 23 as lowest resolution (and drop 24). In my eyes 23 would be easily enough for OSM data (which is largely less accurate anyhow). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Mark Burton escribió: Hello Lambertus, The same problem about crashing MapSource and RoadTrip has also been reported for my maps (e.g. eastern Australia, north and south of Brisbane). The mapbuilding script tries to make those maps as large as possible. Perhaps related is that I upped the max-nodes from 1.400.000 to 1.600.000 for the current map version. I'll reduce the max-nodes for the next update but, ideally, Mkgmap should complain and quit if there is too much information in the source data (This is certainly no complaint, ofcourse I know this all depends on the understanding of the Garmin format). OK - you tell us what the limit is and we'll make sure that mkgmap gripes if you bust the limit. Seriously, if you can provide any info as what works and what doesn't in terms of maps sizes, numbers of lines, polys, nodes, etc. that would be useful and we can code accordingly. I split Spain (from Geofabrik) into 5 tiles using max-nodes=180. I didn't get any crash on MapSource neither any report of crashes from others using my maps. From splitter output: A total of 6.809.701 nodes, 480.959 ways and 10.262 relations were processed in 1 file Output osm.gz files grows up to 27.3 MB and resulting img files up to 22.8 MB Madrid, which is densely mapped (don't know in relation to Athens or Melbourne), is included in one tile of 26.7 MB (osm.gz) and 22.8 MB (img) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
Minko schrieb: Those borderlines form part of different type of administration regions, (countries, provinces, municipalities etc). My question is not to understand why they are tagged like that, but how to make them render them well into mapsource. Is there some kind of patch I can try out, and where/how can I apply it? Im new regarding patching mkgmap, just using the latest release. Chris wrote: what I don't understand: Why is the complex MP processing for borders necessary while we are (mostly) only interested in the border _lines_ ? It was only a guess, that the MP processing destroys your borderlines. Another reason could be that the borders share another way which is drawn with higher priority so that the borderline is disappearing. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
MB Not sure what Chris is referring to there. A couple of things: 1) The current approach where the splitter holds on to any nodes within a certain overlap outside each tile is slightly flawed. For example if a way crosses a tile edge, then if the nearest node in that way which falls outside the tile also falls outside the overlap area, the line segment crossing the tile edge will be lost and hence mkgmap will not be able to join the tiles seamlessly. However I'm yet to see much evidence that this is a problem in practice. 2) Relations that cross tile boundaries aren't preserved in their entirety. This has been discussed on the list recently, and is known to cause problems. Another limitation of the splitter is that it doesn't yet handle relations containing other relations. I'm not sure how much this matters as far as mkgmap is concerned. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] {Spam?} multipolygon with outer polygon within inner polygons
Hello On 12/02/10 10:24, Minko wrote: Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg Thanks for that image as it shows the problem clearly. If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines. I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
FH The problem seems to me, that if a tile has more max-nodes, then a FH very FH dense city (like Athens, Melbourne, ...) in an otherwise rather FH empty FH area (huge tile) will crash. For Athens I had to go as low as FH 600.000, FH for Melbourne 800.000 was fine. FH 1.600.000 is definitely not only crashing a few tiles, but in my FH eyes FH around 10% of European tiles. One thing that is clear is that the limiting factor isn't really the number of nodes in a tile; more likely it's limited by the number (and type?) of ways or relations, or some combination thereof. This is a very difficult (expensive) calculation to perform however when trying to determine where the tile boundaries should fall, so the number of nodes is used as a fairly rough approximation instead. Of course even if there was an efficient way to subdivide based on way/relation counts, we still don't currently know what the rules should be that determine the limits for each tile. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
On 12 Feb 2010, at 7:17 , Chris Miller wrote: FH The problem seems to me, that if a tile has more max-nodes, then a FH very FH dense city (like Athens, Melbourne, ...) in an otherwise rather FH empty FH area (huge tile) will crash. For Athens I had to go as low as FH 600.000, FH for Melbourne 800.000 was fine. FH 1.600.000 is definitely not only crashing a few tiles, but in my FH eyes FH around 10% of European tiles. One thing that is clear is that the limiting factor isn't really the number of nodes in a tile; more likely it's limited by the number (and type?) of ways or relations, or some combination thereof. This is a very difficult (expensive) calculation to perform however when trying to determine where the tile boundaries should fall, so the number of nodes is used as a fairly rough approximation instead. Of course even if there was an efficient way to subdivide based on way/relation counts, we still don't currently know what the rules should be that determine the limits for each tile. to make it even more complicated mkgmap can optimize ways with too many nodes. some imports like Massgis didn't reduce point density. node count in this places will be huge for no benefit in accuracy. optimizing ways can help a lot but how could splitter consider that mkgmap can throw away 50% of all nodes easily another problem in osm data is the number of unused nodes, mainly caused by server/network problems during imports. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Mark Burton wrote: OK - you tell us what the limit is and we'll make sure that mkgmap gripes if you bust the limit. Seriously, if you can provide any info as what works and what doesn't in terms of maps sizes, numbers of lines, polys, nodes, etc. that would be useful and we can code accordingly. I don't know exactly if you were kinda mad at me writing this or if this is a language barrier thing, but please know that I have high respect your and others work on Mkgmap and Splitter. My writing certainly wasn't meant as critique. I'm truly sorry if it was felt that way. That said, is there a tool that gives the statistics that you're looking for from an OSM extract? I would certainly try to provide more useful feedback if possible. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Hi Lambertus, Mark Burton wrote: OK - you tell us what the limit is and we'll make sure that mkgmap gripes if you bust the limit. Seriously, if you can provide any info as what works and what doesn't in terms of maps sizes, numbers of lines, polys, nodes, etc. that would be useful and we can code accordingly. I don't know exactly if you were kinda mad at me writing this or if this is a language barrier thing, but please know that I have high respect your and others work on Mkgmap and Splitter. My writing certainly wasn't meant as critique. I'm truly sorry if it was felt that way. Don't panic, I'm not mad at all - sorry if that's what you thought. The point I was trying to make was simply that we can't add warnings about size limits being busted until we know what the limits are and that info really needs to come from the people who are trying to make big/complex maps. That said, is there a tool that gives the statistics that you're looking for from an OSM extract? I would certainly try to provide more useful feedback if possible. I do not know of such a tool but what we could do is get mkgmap to report a bunch of statistics (number of nodes/ways/relations, subdivisions, routing table sizes, etc.) and that could be correlated against good and bad maps. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
Thanks Steve, So, as I understand it, I need to change the default relation style file in order to convert those multipolygons into lines? When I look at other osm maps from the same area (openmtbmap, radfahrers map, computerteddy) I dont see those connecting lines between the borderlines. Looking at their style files I don't see a difference in how they handle the borders compared to the default style. So... how do they do this, if they use exactly the same osm data? If anybody who want to test it out, I put the osm data here: http://moh.freehostia.com/osm/nassau.osm (200kb, I only downloaded the border polygons of the municipality of Baarle-Nassau). Or an even more simple example can be found at http://moh.freehostia.com/osm/simple.osm (3kb) The last one is not real osm data, but a simplification of the situation. Steve Ratcliffe wrote: Thanks for that image as it shows the problem clearly. If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines. I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Mark Burton (ma...@ordern.com) wrote: I do not know of such a tool but what we could do is get mkgmap to report a bunch of statistics (number of nodes/ways/relations, subdivisions, routing table sizes, etc.) and that could be correlated against good and bad maps. If you could do this, then it would be relatively simple for us to stress test mkgmap against different tiles and so determine acceptable limits for these things relatively quickly. Maybe a --gripe switch? ;) -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong multipolygon warnings
Compiling Spain I get several warnings similar to the one below, that point to data that are correct (or it seems to me). |2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/319017 contains errors. 2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427391078[5P : (44132028[5P]) carries role inner but is not inside any outer polygon. Potentially it does not belong to this multipolygon. |Reported way (hole in the building) lacks in the resulting map. Is it a know bug? Another question, why are polygons so deformed in MapSource compared to Mapnik? Carlos, the way http://www.openstreetmap.org/browse/way/44132028 overlaps the outer way of multipolygon http://www.openstreetmap.org/browse/relation/319017. If we look keenly on the definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) this is not allowed. The current implementation of mkgmap does not support this. But it is widely used. There is a patch (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007086.html) which is not yet committed and which fixes the problem. I think it will be committed within the next days. The deformations do not look good. I think the problem is that mkgmap rounds the exact OSM coordinates to lower resolution garmin coordinates. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Name sequence
Hi,
I created a test map of Tokyo and want to use the name:en
tag for the names.
But I found that changing the name_tag = name:en in the
options file is not working.
Do I also have to change all references to 'name' in the
lines file to 'name:en' ?
# Set highway names to include the reference if there is one
highway=motorway {name '${ref|highway-symbol:hbox} ${name}' |
'${ref|highway-symbol:hbox}' | '${name}' }
highway=trunk {name '${ref|highway-symbol:hbox} ${name}' |
'${ref|highway-symbol:hbox}' | '${name}' }
highway=primary {name '${ref|highway-symbol:box} ${name}' |
'${ref|highway-symbol:box}' | '${name}' }
highway=secondary {name '${ref|highway-symbol:oval} ${name}' |
'${ref|highway-symbol:oval}' | '${name}' }
highway=* {name '${ref} ${name}' | '${ref}' | '${name}' }
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maps crashing Mapsource in big cities
Mark Burton wrote:
Hi Lambertus,
Mark Burton wrote:
OK - you tell us what the limit is and we'll make sure that mkgmap
gripes if you bust the limit.
Seriously, if you can provide any info as what works and what doesn't
in terms of maps sizes, numbers of lines, polys, nodes, etc. that would
be useful and we can code accordingly.
I don't know exactly if you were kinda mad at me writing this or if this
is a language barrier thing, but please know that I have high respect
your and others work on Mkgmap and Splitter. My writing certainly wasn't
meant as critique. I'm truly sorry if it was felt that way.
Don't panic, I'm not mad at all - sorry if that's what you thought. The
point I was trying to make was simply that we can't add warnings about
size limits being busted until we know what the limits are and that
info really needs to come from the people who are trying to make
big/complex maps.
Great, I hoped so :-)
That said, is there a tool that gives the statistics that you're looking
for from an OSM extract? I would certainly try to provide more useful
feedback if possible.
I do not know of such a tool but what we could do is get mkgmap to
report a bunch of statistics (number of nodes/ways/relations,
subdivisions, routing table sizes, etc.) and that could be correlated
against good and bad maps.
If that is thought to be useful then I can upload the statistics to the
website for all tiles on each weekly update and do some extensive
testing when problems are reported. For that I'd apreciate an option to
save the statistics to a file named something like {tilenumber}.stat or
whatever.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
Hello On 12/02/10 10:24, Minko wrote: Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg Thanks for that image as it shows the problem clearly. If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines. I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries. ..Steve Steve, I have two solutions: 1st: We might add a mkgmap option to disable multipolygon processing for boundaries. 2nd: the multipolygon code should not remove the boundary tags from the singular ways. Additionally the polygons created by the multipolygon code could be tagged with mkgmap:mp_boundary=yes. This tag could be evaluated in the style definition so the style could differ between the polygons created by the mp code and the lines not touched by mp code. What do you think? (I am not an expert of the style processing) WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
Thanks Steve, So, as I understand it, I need to change the default relation style file in order to convert those multipolygons into lines? When I look at other osm maps from the same area (openmtbmap, radfahrers map, computerteddy) I dont see those connecting lines between the borderlines. Looking at their style files I don't see a difference in how they handle the borders compared to the default style. So... how do they do this, if they use exactly the same osm data? If anybody who want to test it out, I put the osm data here: http://moh.freehostia.com/osm/nassau.osm (200kb, I only downloaded the border polygons of the municipality of Baarle-Nassau). Or an even more simple example can be found at http://moh.freehostia.com/osm/simple.osm (3kb) The last one is not real osm data, but a simplification of the situation. Minko, the connecting lines are generated by the multipolygon code of mkgmap. It must divide each outer polygon into two halfs to cut out an inner polygon because we don't know a multipolygon type which is supported by the Garmins. We only know garmins single polygon type. So what you see are the cutting lines created by the mkgmap multipolygon code. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
On 12.02.2010 19:26, WanMil wrote:
Hello
On 12/02/10 10:24, Minko wrote:
Simplification looks like this, where the two
vertical border lines are not supposed to be there:
http://img63.imageshack.us/img63/1002/bordersnl5.jpg
Thanks for that image as it shows the problem clearly.
If the boundaries were being drawn as areas, then the lines would
not be seen (or not much anyway) since they would be zero width.
However since the borders are drawn as lines you clearly see the
connecting lines.
I think that the best way to solve this is for mkgmap to convert
to multipolygon into separate lines in the case of boundaries.
..Steve
Steve,
I have two solutions:
1st: We might add a mkgmap option to disable multipolygon processing for
boundaries.
2nd: the multipolygon code should not remove the boundary tags from the
singular ways. Additionally the polygons created by the multipolygon
code could be tagged with mkgmap:mp_boundary=yes. This tag could be
evaluated in the style definition so the style could differ between the
polygons created by the mp code and the lines not touched by mp code.
I think the 2nd solution looks cleaner (or less easy to find out why
something goes wrong). I just gripe about tags being lost. I think it
should rather be converted to:
mkgmap:mp_boundary=${boundary}
mkgmap:mp_admin-level=${admin-level}
in order not to loose the importance. As I'm not well informed about
naming of boundaries, care should be taken not to loose the keys
depicting the info how to name a boundary too.
What do you think? (I am not an expert of the style processing)
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong multipolygon warnings
Hello Carlos, Hi Wanmil, Mapsource capture is as if Mapsource level of details is set to lowest details. If you choose higher or highest LOD, the map should be good. David Le 12/02/2010 19:23, mkgmap-dev-requ...@lists.mkgmap.org.uk a écrit : Compiling Spain I get several warnings similar to the one below, that point to data that are correct (or it seems to me). |2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/319017 contains errors. 2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427391078[5P : (44132028[5P]) carries role inner but is not inside any outer polygon. Potentially it does not belong to this multipolygon. |Reported way (hole in the building) lacks in the resulting map. Is it a know bug? Another question, why are polygons so deformed in MapSource compared to Mapnik? Carlos, the way http://www.openstreetmap.org/browse/way/44132028 overlaps the outer way of multipolygon http://www.openstreetmap.org/browse/relation/319017. If we look keenly on the definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) this is not allowed. The current implementation of mkgmap does not support this. But it is widely used. There is a patch (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007086.html) which is not yet committed and which fixes the problem. I think it will be committed within the next days. The deformations do not look good. I think the problem is that mkgmap rounds the exact OSM coordinates to lower resolution garmin coordinates. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong multipolygon warnings
David escribió: Hello Carlos, Hi Wanmil, Mapsource capture is as if Mapsource level of details is set to lowest details. If you choose higher or highest LOD, the map should be good. I'm afraid the level of detail used for the capture was the highest. FYI, I don't see any difference changing to other levels. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong multipolygon warnings
WanMil escribi: Am 12.02.2010 20:06, schrieb Carlos Dvila: WanMil escribi: Compiling Spain I get several warnings similar to the one below, that point to data that are correct (or it seems to me). |2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/319017 contains errors. 2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427391078[5P : (44132028[5P]) carries role inner but is not inside any outer polygon. Potentially it does not belong to this multipolygon. |Reported way (hole in the building) lacks in the resulting map. Is it a know bug? Another question, why are polygons so deformed in MapSource compared to Mapnik? Carlos, the way http://www.openstreetmap.org/browse/way/44132028 overlaps the outer way of multipolygon http://www.openstreetmap.org/browse/relation/319017. If we look keenly on the definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) this is not allowed. The current implementation of mkgmap does not support this. Way 44132028 doesn't really overlap the outer polygon. They are separated some 25 cm, but mkgmap seems to consider them overlapping. ~25cm is much below mkgmap resolution (I think so...) I knew about ~4.7m garmin limit for routing, but didn't know such limit affected other things. But it is widely used. There is a patch (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007086.html) which is not yet committed and which fixes the problem. I think it will be committed within the next days. I'll test it and give feedback Thanks! That will speed up the commit. I'm not very fit with patches. I tried patch -p 1 mp_linesoverlapping_v1.patch within mkgmap root directory, but it didn't work Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED Can you give me some hint? The deformations do not look good. I think the problem is that mkgmap rounds the exact OSM coordinates to lower resolution garmin coordinates. May it be also the origin of the overlapping problem in the above case? Yes, propably. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong multipolygon warnings
I'll test it and give feedback Thanks! That will speed up the commit. I'm not very fit with patches. I tried |patch -p 1 mp_linesoverlapping_v1.patch| within mkgmap root directory, but it didn't work |Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED| Can you give me some hint? I am also no expert for patching. I use the Eclipse patch so I don't know any parameters. One basic question: Did you patch the source code? Patching does not work with the binary distribution. You must patch the source code and recompile mkgmap. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong multipolygon warnings
WanMil escribió: I'll test it and give feedback Thanks! That will speed up the commit. I'm not very fit with patches. I tried |patch -p 1 mp_linesoverlapping_v1.patch| within mkgmap root directory, but it didn't work |Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED| Can you give me some hint? I am also no expert for patching. I use the Eclipse patch so I don't know any parameters. One basic question: Did you patch the source code? Patching does not work with the binary distribution. You must patch the source code and recompile mkgmap. Yes, I tried to patch the source code. My knowledge is enough for that ;-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1566: Drop all tags from the osm file that are not used
On Thu, Feb 11, 2010 at 07:59:01PM +0100, WanMil wrote:
The Osm5XMLHandler sometimes throw a NullPointerException in line 397.
This is the key.equals(highway) part:
if((val.equals(motorway_junction) ||
val.equals(services))
key.equals(highway))
{
exits.add(currentNode);
currentNode.addTag(osm:id, + currentElementId);
}
It might be fixed by changing it to highway.equals(key).
Right, java.lang.Object.equals(Object other) specifically says that you can
pass other=null and the result will be false. On the other hand, invoking
a method on a null reference will throw a NullPointerException.
Marko
After the commit it's working!
The speed improvements are great (I usually create maps using only very
few tags).
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Wrong multipolygon warnings
Am 12.02.2010 21:57, schrieb Carlos Dávila:
WanMil escribió:
I'll test it and give feedback
Thanks! That will speed up the commit.
I'm not very fit with patches. I tried |patch -p 1
mp_linesoverlapping_v1.patch| within mkgmap root directory, but it
didn't work
|Hunk #1 FAILED at 38.
Hunk #2 FAILED at 397.
Hunk #3 FAILED at 407.
Hunk #4 FAILED at 494.
Hunk #5 FAILED at 509.
Hunk #6 FAILED at 648.
Hunk #7 FAILED at 671.
Hunk #8 FAILED at 698.
Hunk #9 FAILED at 843.
Hunk #10 FAILED at 945.
Hunk #11 FAILED at 1028.
Hunk #12 FAILED at 1071.
Hunk #13 FAILED at 1085.
Hunk #14 FAILED at 1119.
Hunk #15 FAILED at 1129.
Hunk #16 FAILED at 1171.
Hunk #17 FAILED at 1183.
Hunk #18 FAILED at 1227.
Hunk #19 FAILED at 1259.
Hunk #20 FAILED at 1442.
Hunk #21 FAILED at 1462.
21 out of 21 hunks FAILED|
Can you give me some hint?
I am also no expert for patching. I use the Eclipse patch so I don't
know any parameters.
One basic question: Did you patch the source code? Patching does not
work with the binary distribution. You must patch the source code and
recompile mkgmap.
Yes, I tried to patch the source code. My knowledge is enough for that ;-)
Ok, this was a silly question. But it was the only idea I have...
Maybe there is a problem that the first patch was against rev 1563.
I have attached a patch for revision 1568. Hopefully this will work...?!?
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(revision 1568)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(working copy)
@@ -1,6 +1,7 @@
package uk.me.parabola.mkgmap.reader.osm;
-import java.awt.*;
+import java.awt.Polygon;
+import java.awt.Rectangle;
import java.awt.geom.Area;
import java.awt.geom.Line2D;
import java.awt.geom.PathIterator;
@@ -37,11 +38,19 @@
private final MapLong, String roleMap = new HashMapLong, String();
private ArrayListBitSet containsMatrix;
- private ArrayListJoinedWay rings;
- private SetJoinedWay intersectingRings;
+ private ArrayListJoinedWay polygons;
+ private SetJoinedWay intersectingPolygons;
private final uk.me.parabola.imgfmt.app.Area bbox;
+ /**
+* A point that has a lower or equal squared distance from
+* a line is treated as if it lies one the line.br/
+* 1.0d is very exact. 2.0d covers rounding problems when converting
+* OSM locations to mkgmap internal format. A larger value
+* is more tolerant against imprecise OSM data.
+*/
+ private final double OVERLAP_TOLERANCE_DISTANCE = 2.0d;
/**
* if one of these tags are contained in the multipolygon then the outer
@@ -416,72 +425,71 @@
}
}
}
-
+
/**
-* Find all rings that are not contained by any other ring.
+* Find all polygons that are not contained by any other polygon.
*
* @param candidates
-*all rings that should be checked
+*all polygons that should be checked
* @param roleFilter
*an additional filter
-* @return all ring indexes that are not contained by any other ring
+* @return all polygon indexes that are not contained by any other
polygon
*/
- private BitSet findOutmostRings(BitSet candidates, BitSet roleFilter) {
+ private BitSet findOutmostPolygons(BitSet candidates, BitSet
roleFilter) {
BitSet realCandidates = ((BitSet) candidates.clone());
realCandidates.and(roleFilter);
- return findOutmostRings(realCandidates);
+ return findOutmostPolygons(realCandidates);
}
/**
-* Finds all rings that are not contained by any other rings and that
match
-* to the given role. All rings with index given by
varcandidates/var
+* Finds all polygons that are not contained by any other polygons and
that match
+* to the given role. All polygons with index given by
varcandidates/var
* are used.
*
* @param candidates
-*indexes of the rings that should be used
-* @return the bits of all outmost rings are set to true
+*indexes of the polygons that should be used
+* @return the bits of all outmost polygons are set to true
*/
- private BitSet findOutmostRings(BitSet candidates) {
- BitSet outmostRings = new BitSet();
+ private BitSet findOutmostPolygons(BitSet candidates) {
+ BitSet outmostPolygons = new BitSet();
// go through all candidates and check if they are contained by
any
// other candidate
for (int candidateIndex = candidates.nextSetBit(0);
Re: [mkgmap-dev] Wrong multipolygon warnings
WanMil escribió: Am 12.02.2010 21:57, schrieb Carlos Dávila: WanMil escribió: I'll test it and give feedback Thanks! That will speed up the commit. I'm not very fit with patches. I tried |patch -p 1 mp_linesoverlapping_v1.patch| within mkgmap root directory, but it didn't work |Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED| Can you give me some hint? I am also no expert for patching. I use the Eclipse patch so I don't know any parameters. One basic question: Did you patch the source code? Patching does not work with the binary distribution. You must patch the source code and recompile mkgmap. Yes, I tried to patch the source code. My knowledge is enough for that ;-) Ok, this was a silly question. But it was the only idea I have... Maybe there is a problem that the first patch was against rev 1563. I have attached a patch for revision 1568. Hopefully this will work...?!? Finally I could apply your patch moving it to the right directory. I'll test it tomorrow and give feedback. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
