[mkgmap-dev] Splitter problem: losing a track segment
From GerdP gpetermann_muenchen at hotmail.com on Tue Jun 2 13:34:59 BST 2015
Hi Alexandre, well, the advantage of the keep-complete option is that you don't need the large overlap and still get complete ways and relations, so it's about disk usage, memory and quality. As long as you files are rather small you can probably use a large overlap value instead. Maybe you can calculate the needed overlap in your generator. ciao, Gerd Alexandre Loss wrote > Hi Gerd, > > I already made a previous analysis before to change my generator. Well, > it's possible, but I practically have to rebuild the generator entirely. > So, I understood that you said that it's better solution but not a "must" > solution to change generator. If so, I will prefer to keep the generator > this way for a while. > However, If you think I can be missing something in my maps due this mixed > syntax, then I will plan to change my code. > > Thanks > > Alexandre > > 2015-06-02 2:36 GMT-03:00 Gerd Petermann < > gpetermann_muenchen@ > >: > >> Hi Alexandre, >> >> the better solution would be to change your generator so that >> it writes the data in the expected order (nodes, ways, relations, each >> with >> ascending ids). If you do that, you can remove the options --mixed and >> --overlap >> and use the default --keep-complete=true. >> >> A possible compromise: >> I have to double check that, but I think the keep-complete option only >> requires that >> the ids are sorted, it doesn't care about the order of the elements. >> On the other hand, the xml parser requires the >> mixed option when the element types are not sorted, >> and a check prohibtis the combination of --mixed and keep-complete=true. >> If I am right, I can remove this check. >> >> Ciao, >> Gerd >> >> ------------------------------ >> Date: Sat, 30 May 2015 09:15:19 -0300 >> From: > alexandre.loss@ >> To: > mkgmap-dev at .org >> Subject: Re: [mkgmap-dev] Splitter problem: losing a track segment >> >> >> Hi Gerd, >> >> Overlap of 10000 fixed my problem. :-) >> >> Thank you very much! >> >> Alexandre >> >> 2015-05-30 8:20 GMT-03:00 Alexandre Loss < > alexandre.loss@ > >: >> >> Hi Gerd, >> >> Thanks for your answer. >> I'll try your suggestion and give you a feedback about the result. >> >> Regards, >> >> Alexandre >> >> 2015-05-30 5:43 GMT-03:00 Gerd Petermann < > gpetermann_muenchen@ > > >> : >> >> Hi Alexandre, >> >> I don't have much time to analyse your data today. >> I think splitter assumes that the tile boundaries >> are >> "multiples of 0x200 map units wide and high" >> when you use resolution=15. >> >> Since you use keep-complete=false you have to watch >> the overlap value. >> You can use a larger overlap value like 10000 to fix this problem. >> >> Gerd >> >> >> ------------------------------ >> Date: Fri, 29 May 2015 22:04:34 -0300 >> From: > alexandre.loss@ >> To: > mkgmap-dev at .org >> Subject: [mkgmap-dev] Splitter problem: losing a track segment >> >> >> Hi guys, >> >> I'm facing a problem in one of my maps, that is probably might be >> happening in other places where I didn't see yet. >> The problem can be seen in the figure below taken from MapSource. There >> is >> a gap in a track on the border of the tiles: >> >> [image: Imagem inline 2] >> >> So I started to analyze the problem step-by-step till find that the >> problem was generated by Splitter (last version). >> >> To simplify your analysis, I edited my .osm file before running Splitter >> and remove all objects (nodes, lines, poi, etc.) not related to the >> problem, leaving only the line where the problem happens. The result was >> the file "93352150-Ribeirao_Preto.osm" attached, containing only this: >> >> <?xml version="1.0" encoding="UTF-8"?> >> > <osm version="0.6" generator="TSuite 6.6.0.4"> >> >> > <node id="576" lat="-21.9388623" lon="-48.3347007" visible="true" >> > version="1"/> >> > <node id="805" lat="-21.8877920" lon="-48.2932640" visible="true" >> > version="1"/> >> > <node id="806" lat="-21.8674906" lon="-48.2767485" visible="true" >> > version="1"/> >> > <node id="804" lat="-21.8661147" lon="-48.2756044" visible="true" >> > version="1"/> >> > <way id="803" visible="true" version="1"> >> > <nd ref="576"/> >> > <nd ref="805"/> >> > <nd ref="806"/> >> > <nd ref="804"/> >> > <tag k="highway" v="trunk"/> >> > <tag k="name" v="SP-255 DANIELLE"/> >> > <tag k="ref" v="SP-255"/> >> > <tag k="addr:city" v="BOA ESPERANÇA DO SUL"/> >> > <tag k="addr:state" v="SP"/> >> > <tag k="addr:country" v="Brasil"/> >> > </way> >> >> > </osm> >> >> Then I ran Splitter on this file and the result was the file >> "93352150.osm" (attached and compacted), whose content are the lines >> bellow: >> >> <?xml version='1.0' encoding='UTF-8'?> >> > <osm version='0.5' generator='splitter' upload='false'> >> > <bounds minlat='-21.895751953125' minlon='-50.262451171875' >> > maxlat='-20.401611328125' maxlon='-47.548828125'/> >> > <node id='805' lat='-21.8877920' lon='-48.2932640'/> >> > <node id='806' lat='-21.8674906' lon='-48.2767485'/> >> > <node id='804' lat='-21.8661147' lon='-48.2756044'/> >> > <way id='803'> >> > <nd ref='576'/> >> > <nd ref='805'/> >> > <nd ref='806'/> >> > <nd ref='804'/> >> > <tag k='highway' v='trunk'/> >> > <tag k='name' v='SP-255 DANIELLE'/> >> > <tag k='ref' v='SP-255'/> >> > <tag k='addr:city' v='BOA ESPERANÇA DO SUL'/> >> > <tag k='addr:state' v='SP'/> >> > <tag k='addr:country' v='Brasil'/> >> > </way> >> > </osm> >> >> Note that in the "93352150.osm" file is missing the node 576 definition >> (i.e.: > <node id="576" lat="-21.9388623" lon="-48.3347007" visible="true" >> > version="1"/>). >> And this is the cause of the lost segment. >> >> I'm running Splitter in the following way: >> >> java -jar splitter.jar --split-file=93352150-Ribeirao_Preto.list >> --max-areas=1024 --mixed=true --keep-complete=false --resolution=15 >> --output=xml 93352150-Ribeirao_Preto.osm >> >> The above .list file is attached. >> >> If this is not a Splitter error, please, let me know what I'm doing >> wrong. >> >> Thanks. >> >> Alexandre >> >> >> _______________________________________________ mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> >> >> _______________________________________________ mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at .org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > image.png (12K) > <http://gis.19327.n5.nabble.com/attachment/5846805/0/image.png> Alexandre Loss wrote > Hi Gerd, > > I already made a previous analysis before to change my generator. Well, > it's possible, but I practically have to rebuild the generator entirely. > So, I understood that you said that it's better solution but not a "must" > solution to change generator. If so, I will prefer to keep the generator > this way for a while. > However, If you think I can be missing something in my maps due this mixed > syntax, then I will plan to change my code. > > Thanks > > Alexandre > > 2015-06-02 2:36 GMT-03:00 Gerd Petermann < > gpetermann_muenchen@ > >: > >> Hi Alexandre, >> >> the better solution would be to change your generator so that >> it writes the data in the expected order (nodes, ways, relations, each >> with >> ascending ids). If you do that, you can remove the options --mixed and >> --overlap >> and use the default --keep-complete=true. >> >> A possible compromise: >> I have to double check that, but I think the keep-complete option only >> requires that >> the ids are sorted, it doesn't care about the order of the elements. >> On the other hand, the xml parser requires the >> mixed option when the element types are not sorted, >> and a check prohibtis the combination of --mixed and keep-complete=true. >> If I am right, I can remove this check. >> >> Ciao, >> Gerd >> >> ------------------------------ >> Date: Sat, 30 May 2015 09:15:19 -0300 >> From: > alexandre.loss@ >> To: > mkgmap-dev at .org >> Subject: Re: [mkgmap-dev] Splitter problem: losing a track segment >> >> >> Hi Gerd, >> >> Overlap of 10000 fixed my problem. :-) >> >> Thank you very much! >> >> Alexandre >> >> 2015-05-30 8:20 GMT-03:00 Alexandre Loss < > alexandre.loss@ > >: >> >> Hi Gerd, >> >> Thanks for your answer. >> I'll try your suggestion and give you a feedback about the result. >> >> Regards, >> >> Alexandre >> >> 2015-05-30 5:43 GMT-03:00 Gerd Petermann < > gpetermann_muenchen@ > > >> : >> >> Hi Alexandre, >> >> I don't have much time to analyse your data today. >> I think splitter assumes that the tile boundaries >> are >> "multiples of 0x200 map units wide and high" >> when you use resolution=15. >> >> Since you use keep-complete=false you have to watch >> the overlap value. >> You can use a larger overlap value like 10000 to fix this problem. >> >> Gerd >> >> >> ------------------------------ >> Date: Fri, 29 May 2015 22:04:34 -0300 >> From: > alexandre.loss@ >> To: > mkgmap-dev at .org >> Subject: [mkgmap-dev] Splitter problem: losing a track segment >> >> >> Hi guys, >> >> I'm facing a problem in one of my maps, that is probably might be >> happening in other places where I didn't see yet. >> The problem can be seen in the figure below taken from MapSource. There >> is >> a gap in a track on the border of the tiles: >> >> [image: Imagem inline 2] >> >> So I started to analyze the problem step-by-step till find that the >> problem was generated by Splitter (last version). >> >> To simplify your analysis, I edited my .osm file before running Splitter >> and remove all objects (nodes, lines, poi, etc.) not related to the >> problem, leaving only the line where the problem happens. The result was >> the file "93352150-Ribeirao_Preto.osm" attached, containing only this: >> >> <?xml version="1.0" encoding="UTF-8"?> >> > <osm version="0.6" generator="TSuite 6.6.0.4"> >> >> > <node id="576" lat="-21.9388623" lon="-48.3347007" visible="true" >> > version="1"/> >> > <node id="805" lat="-21.8877920" lon="-48.2932640" visible="true" >> > version="1"/> >> > <node id="806" lat="-21.8674906" lon="-48.2767485" visible="true" >> > version="1"/> >> > <node id="804" lat="-21.8661147" lon="-48.2756044" visible="true" >> > version="1"/> >> > <way id="803" visible="true" version="1"> >> > <nd ref="576"/> >> > <nd ref="805"/> >> > <nd ref="806"/> >> > <nd ref="804"/> >> > <tag k="highway" v="trunk"/> >> > <tag k="name" v="SP-255 DANIELLE"/> >> > <tag k="ref" v="SP-255"/> >> > <tag k="addr:city" v="BOA ESPERANÇA DO SUL"/> >> > <tag k="addr:state" v="SP"/> >> > <tag k="addr:country" v="Brasil"/> >> > </way> >> >> > </osm> >> >> Then I ran Splitter on this file and the result was the file >> "93352150.osm" (attached and compacted), whose content are the lines >> bellow: >> >> <?xml version='1.0' encoding='UTF-8'?> >> > <osm version='0.5' generator='splitter' upload='false'> >> > <bounds minlat='-21.895751953125' minlon='-50.262451171875' >> > maxlat='-20.401611328125' maxlon='-47.548828125'/> >> > <node id='805' lat='-21.8877920' lon='-48.2932640'/> >> > <node id='806' lat='-21.8674906' lon='-48.2767485'/> >> > <node id='804' lat='-21.8661147' lon='-48.2756044'/> >> > <way id='803'> >> > <nd ref='576'/> >> > <nd ref='805'/> >> > <nd ref='806'/> >> > <nd ref='804'/> >> > <tag k='highway' v='trunk'/> >> > <tag k='name' v='SP-255 DANIELLE'/> >> > <tag k='ref' v='SP-255'/> >> > <tag k='addr:city' v='BOA ESPERANÇA DO SUL'/> >> > <tag k='addr:state' v='SP'/> >> > <tag k='addr:country' v='Brasil'/> >> > </way> >> > </osm> >> >> Note that in the "93352150.osm" file is missing the node 576 definition >> (i.e.: > <node id="576" lat="-21.9388623" lon="-48.3347007" visible="true" >> > version="1"/>). >> And this is the cause of the lost segment. >> >> I'm running Splitter in the following way: >> >> java -jar splitter.jar --split-file=93352150-Ribeirao_Preto.list >> --max-areas=1024 --mixed=true --keep-complete=false --resolution=15 >> --output=xml 93352150-Ribeirao_Preto.osm >> >> The above .list file is attached. >> >> If this is not a Splitter error, please, let me know what I'm doing >> wrong. >> >> Thanks. >> >> Alexandre >> >> >> _______________________________________________ mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> >> >> _______________________________________________ mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at .org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > image.png (12K) > <http://gis.19327.n5.nabble.com/attachment/5846805/0/image.png> -- View this message in context: http://gis.19327.n5.nabble.com/Splitter-problem-losing-a-track-segment-tp5846557p5846806.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
- Previous message: [mkgmap-dev] Splitter problem: losing a track segment
- Next message: [mkgmap-dev] Splitter problem: losing a track segment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list