Splitter Options for small files
Is there (or could there be) an option in Splitter such that if it finds an input file which will be 'split' into only one tile, it will just copy and rename it without further processing? This has arisen because in processing a group of tiles of varying size (some but not all of which need splitting), I have been getting artefacts (gaps between tiles). These disappeared when the original small tiles, rather than the 'single split' tiles were used. Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
Roger Calvert wrote
Is there (or could there be) an option in Splitter such that if it finds an input file which will be 'split' into only one tile, it will just copy and rename it without further processing?
There is no such option. See below. Roger Calvert wrote
This has arisen because in processing a group of tiles of varying size (some but not all of which need splitting), I have been getting artefacts (gaps between tiles). These disappeared when the original small tiles, rather than the 'single split' tiles were used.
I see two possible reasons: 1) splitter creates a new bounding box which is aligned to 2048 garmin units, it will "blow up" the original bbox if needed. 2) If the input file contains a bounding box, splitter doesn't copy data that lies outside of this bbox. I assume the problem is caused by the 2nd reason, and that means, you can have those artefacts also when the file is split into more than one tile. A possible solution would be to tell splitter to ignore the bounding box of the input file. Could you try that ? Or can you tell me how to reproduce the problem ? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Splitter-Options-for-small-files-tp5743455p57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
GerdP wrote
I see two possible reasons: 1) splitter creates a new bounding box which is aligned to 2048 garmin units, it will "blow up" the original bbox if needed. 2) If the input file contains a bounding box, splitter doesn't copy data that lies outside of this bbox.
Sorry, forget 2) Splitter calculates the bounding box in this way: it starts with an empty bbox. if a bounding box is found in the input file, this is used to enlarge splitters bbox it enlarges the bbox for each node in the input file that lies outside of the bbox The result is reported in the line starting "Exact map coverage is " The next line begiining with ""Rounded map coverage is " shows the bbox that is written to the output file. If I got this right, mkgmap should not have a problem with that. If it does, the problem should be fixed in mkgmap. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Splitter-Options-for-small-files-tp5743455p57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hmm, sorry, I was wrong again :-( If splitter finds a bbox in the input file, this bbox is used and all data outside of the bbox is ignored (maybe not with --keep-complete=true ). Typically, nodes outside of the bbox belong to ways that have also nodes inside of the bbox. So, the question is if we solve the problem if we ignore the bbox of the input file or if we simply copy the input file when it is small. Do you have the problem with --keep-complete=true? Gerd GerdP wrote
GerdP wrote
I see two possible reasons: 1) splitter creates a new bounding box which is aligned to 2048 garmin units, it will "blow up" the original bbox if needed. 2) If the input file contains a bounding box, splitter doesn't copy data that lies outside of this bbox. Sorry, forget 2) Splitter calculates the bounding box in this way: it starts with an empty bbox. if a bounding box is found in the input file, this is used to enlarge splitters bbox it enlarges the bbox for each node in the input file that lies outside of the bbox
The result is reported in the line starting "Exact map coverage is " The next line begiining with ""Rounded map coverage is " shows the bbox that is written to the output file.
If I got this right, mkgmap should not have a problem with that. If it does, the problem should be fixed in mkgmap.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Splitter-Options-for-small-files-tp5743455p57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Gerd, I have been looking at the split files. The bounds are, as you say in your explanation (1), adjusted slightly. For example, latitude 43.0 on the original tile becomes 43.06 on the split tile. This occurs on both tiles, so the lower tile will gain 0.06 deg in which it has no data, and the upper one will lose its data in this gap. 0.06 deg of latitude is several km, so this accounts for my gaps. The moral is, don't split tiles which don't need splitting! (Presumably this always occurs at the edges of split areas, but cancels out internally when the tiles come from one larger one.) Thanks again for guiding me through to the explanation. Roger On 08/01/2013 19:07, GerdP wrote:
Hmm, sorry, I was wrong again :-(
If splitter finds a bbox in the input file, this bbox is used and all data outside of the bbox is ignored (maybe not with --keep-complete=true ). Typically, nodes outside of the bbox belong to ways that have also nodes inside of the bbox.
So, the question is if we solve the problem if we ignore the bbox of the input file or if we simply copy the input file when it is small. Do you have the problem with --keep-complete=true?
Gerd
GerdP wrote
GerdP wrote
I see two possible reasons: 1) splitter creates a new bounding box which is aligned to 2048 garmin units, it will "blow up" the original bbox if needed. 2) If the input file contains a bounding box, splitter doesn't copy data that lies outside of this bbox. Sorry, forget 2) Splitter calculates the bounding box in this way: it starts with an empty bbox. if a bounding box is found in the input file, this is used to enlarge splitters bbox it enlarges the bbox for each node in the input file that lies outside of the bbox
The result is reported in the line starting "Exact map coverage is " The next line begiining with ""Rounded map coverage is " shows the bbox that is written to the output file.
If I got this right, mkgmap should not have a problem with that. If it does, the problem should be fixed in mkgmap.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Splitter-Options-for-small-files-tp5743455p57... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ------------------------------------------------------------------------ Roger Calvert Beckside House Blawith Ulverston LA12 8EQ 01229 885498 078 2746 8501 ------------------------------------------------------------------------
Roger Calvert wrote
I have been looking at the split files. The bounds are, as you say in your explanation (1), adjusted slightly. For example, latitude 43.0 on the original tile becomes 43.06 on the split tile. This occurs on both tiles, so the lower tile will gain 0.06 deg in which it has no data, and the upper one will lose its data in this gap. 0.06 deg of latitude is several km, so this accounts for my gaps.
I think you report problems that are long fixed now. What version of splitter are you using? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Splitter-Options-for-small-files-tp5743455p57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 08/01/2013 21:58, GerdP wrote:
Roger Calvert wrote
I have been looking at the split files. The bounds are, as you say in your explanation (1), adjusted slightly. For example, latitude 43.0 on the original tile becomes 43.06 on the split tile. This occurs on both tiles, so the lower tile will gain 0.06 deg in which it has no data, and the upper one will lose its data in this gap. 0.06 deg of latitude is several km, so this accounts for my gaps. I think you report problems that are long fixed now. What version of splitter are you using? I was using r202 . Just installed r270, and the problem is resolved!
Thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert Beckside House Blawith Ulverston LA12 8EQ 01229 885498 078 2746 8501 ------------------------------------------------------------------------
Roger Calvert wrote
I was using r202 . Just installed r270, and the problem is resolved!
Thanks, Roger. That is good to know :-) -- View this message in context: http://gis.19327.n5.nabble.com/Splitter-Options-for-small-files-tp5743455p57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (2)
-
GerdP -
Roger Calvert