I've just started using the --generate-sea option, and it almost works. The problem is that of the UK, the whole of northern Scotland (north of a line through Stirling) is inverted - i.e. the land is blue and the sea is light yellow (black at night). This is inconvenient, as that's where I live. What's the likely cause? Could it be due to an island that's tagged in the wrong direction? I've checked the most northerly and most westerly islands and they all look okay to me. GeoFabrik's OSM Inspector doesn't flag up any coastline errors in that area, so that's no help. I could probably dig out the splitter log if that's any use - on the screen, this problem does seem to affect more than one of the output files - but it does look suspicious that the affected files are all contiguous.
On Oct 25, 2009, at 22:24, Toby Speight wrote:
I've just started using the --generate-sea option, and it almost works. The problem is that of the UK, the whole of northern Scotland (north of a line through Stirling) is inverted - i.e. the land is blue and the sea is light yellow (black at night). This is inconvenient, as that's where I live.
What's the likely cause?
I think this option still needs to be refined. I have downloaded coastline extracts and specially processed them (for a separate sea layer), and have had similar problems. The data I was working on did not need to be split, so I think you can rule the splitter out as being part of the problem. It seems that under certain circumstances the generate-sea option inverts land and sea. Cheers.
0> In article <5175AA64-611C-44BB-AA72-DC87DBB3EB6E@googlemail.com>, 0> Clinton Gladstone <URL:mailto:clinton.gladstone@googlemail.com> ("Clinton") wrote: Clinton> I think this option [--generate-sea] still needs to be refined. Clinton> I have downloaded coastline extracts and specially processed Clinton> them (for a separate sea layer), and have had similar problems. Clinton> The data I was working on did not need to be split, so I think Clinton> you can rule the splitter out as being part of the problem. Clinton> Clinton> It seems that under certain circumstances the generate-sea Clinton> option inverts land and sea. Thanks. I've not used osmosis before, but it appears it can extract the coastline for separate processing, so I should be able to create smaller extracts to experiment with. Then I can look into the code myself. (But not today; it's too nice to stay indoors!)
Toby Speight schrieb:
I've just started using the --generate-sea option, and it almost works. The problem is that of the UK, the whole of northern Scotland (north of a line through Stirling) is inverted - i.e. the land is blue and the sea is light yellow (black at night). This is inconvenient, as that's where I live.
What's the likely cause? Could it be due to an island that's tagged in the wrong direction? I've checked the most northerly and most westerly islands and they all look okay to me. GeoFabrik's OSM Inspector doesn't flag up any coastline errors in that area, so that's no help.
Could you provide me a download link for the offending tile? Did mkgmap print a warning message "Non-closed coastline segment does not hit bounding box: ..."? The algorithm I implemented handles two cases of land masses: - closed shoreline segments (aka islands) - shoreline segments which are not closed but extend to the border of the tile (i.e. the intersection of a closed shoreline with the bounding box) In the latter case the shoreline is "closed" along the tile border. The algorithm then generates a sea background and a multipolygon relation which adds a "hole" for each landmass. Obviously a landmass with a non-closed boundary will be drowned by that approach :-) One limitation I know of arises with country extracts from geofabrik - they have shorelines cut-off at the country border. As UK is a big island, this should not be the cause of your problem, though. Best wishes Christian
0> In article <4AE592A2.7060209@gmx.de>, 0> Christian Gawron <URL:mailto:christian.gawron@googlemail.com> ("CG") wrote: CG> Could you provide me a download link for the offending tile? I don't have a server I can put it on, but I'm using Geofabrik's "Great Britain" extract[1], and this is the relevant line from the splitter: /-------- | 63240015: 2615296,-407552 to 2846720,102400 | # : 56.118164,-8.745117 to 61.083984,2.197266 \-------- [1] <URL: http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 > CG> Did mkgmap print a warning message "Non-closed coastline segment does CG> not hit bounding box: ..."? I didn't see any, but they may have been lost amongst a slew of "zero length arc" messages from the roads. I'm re-running the build, so I can throw grep at the logs. [time passes] No, definitely no occurrence of the word "coastline" in the output. CG> CG> The algorithm I implemented handles two cases of land masses: CG> - closed shoreline segments (aka islands) ... or inland seas (if clockwise)? CG> - shoreline segments which are not closed but extend to the border CG> of the tile (i.e. the intersection of a closed shoreline with the CG> bounding box) CG> CG> In the latter case the shoreline is "closed" along the tile border. CG> The algorithm then generates a sea background and a multipolygon CG> relation which adds a "hole" for each landmass. Obviously a landmass CG> with a non-closed boundary will be drowned by that approach :-) I would expect any non-closed coastlines to show up in OSM Inspector, and I'm not seeing anything there. I'm wondering how the closure of cut shorelines is done (having not yet looked at the code), and perhaps it is turning right instead of left for some reason? CG> One limitation I know of arises with country extracts from geofabrik - CG> they have shorelines cut-off at the country border. As UK is a big CG> island, this should not be the cause of your problem, though. One big island and several hundred small islands, but yes, there's no coastline hitting the edge of the extract (Ireland is not included). Also, in passing, is it normal to have lots of little blue "threads" appear on the GPS display connecting the sea regions? I've not seen this with other multipolygons, so I'm wondering if this is also a symptom of problems.
Toby Speight schrieb:
0> In article <4AE592A2.7060209@gmx.de>, 0> Christian Gawron <URL:mailto:christian.gawron@googlemail.com> ("CG") wrote:
CG> Could you provide me a download link for the offending tile?
I don't have a server I can put it on, but I'm using Geofabrik's "Great Britain" extract[1], and this is the relevant line from the splitter:
/-------- | 63240015: 2615296,-407552 to 2846720,102400 | # : 56.118164,-8.745117 to 61.083984,2.197266 \--------
[1] <URL: http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 >
Ok, I will have a look at it. I'm not so familiar with the newest version of the splitter - how can I tell it to create the tile 63240015 with the coordinates above? Can you send me the areas.list?
CG> CG> The algorithm I implemented handles two cases of land masses: CG> - closed shoreline segments (aka islands)
... or inland seas (if clockwise)?
Are there really inland seas using natural=shoreline instead of natural=water?
CG> - shoreline segments which are not closed but extend to the border CG> of the tile (i.e. the intersection of a closed shoreline with the CG> bounding box) CG> CG> In the latter case the shoreline is "closed" along the tile border. CG> The algorithm then generates a sea background and a multipolygon CG> relation which adds a "hole" for each landmass. Obviously a landmass CG> with a non-closed boundary will be drowned by that approach :-)
I would expect any non-closed coastlines to show up in OSM Inspector, and I'm not seeing anything there. No, they are usually a result of some cutting process. I'm wondering how the closure of cut shorelines is done (having not yet looked at the code), and perhaps it is turning right instead of left for some reason?
No, the turning direction should be correct.
Also, in passing, is it normal to have lots of little blue "threads" appear on the GPS display connecting the sea regions? I've not seen this with other multipolygons, so I'm wondering if this is also a symptom of problems.
No, this is part of the multipolygon code. It connects the inner and outer polygons with two lines, and the coordinates of the "returning" line are move by one map unit. There is a comment in the code stating that this results in "triangles" but that it is necessary or some "inner" polygons are not rendered at all. I must admit that I don't really understand how polygons with "holes" should be coded in the IMG file. Best wishes Christian
0> In article <4AE75888.8060206@gmx.de>, 0> Christian Gawron <URL:mailto:christian.gawron@gmx.de> ("CG") wrote: CG> Toby Speight schrieb:
I don't have a server I can put it on, but I'm using Geofabrik's "Great Britain" extract[1], and this is the relevant line from the splitter:
/-------- | 63240015: 2615296,-407552 to 2846720,102400 | # : 56.118164,-8.745117 to 61.083984,2.197266 \--------
[1] <URL: http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 >
CG> Ok, I will have a look at it. I'm not so familiar with the CG> newest version of the splitter - how can I tell it to create CG> the tile 63240015 with the coordinates above? Can you send me CG> the areas.list?
I could give you the full areas.list (I don't know whether you can make splitter create a single tile) - but - I'm experimenting with cutting out smaller extracts using osmosis, to see whether I can produce a smaller file that still triggers the problem. I did manage to reproduce it by extracting just the coastline from great_britain.osm: /-------- | osmosis --read-xml $< --way-key-value keyValueList='natural.coastline' --used-node --write-xml $@ \-------- This gives a file containing only the coastline, which can be processed without splitting. And, for me, this exhibits the inversion. It does take quite a while to run through mkgmap, unfortunately (an hour of CPU time for me), so I'm looking at cutting it down to process smaller groups of islands. I might not get it done today, though, and I'm about to go off-line for a few days (back around the middle of next week). BTW, I was wrong about this affecting multiple areas of the GB extract - the other boundaries I saw were from my contour tiles, not general OSM. CG> Are there really inland seas using natural=shoreline instead of CG> natural=water? I've no idea - not in my region, I would think, but perhaps the Dead Sea? Let's not worry about this for now!
Also, in passing, is it normal to have lots of little blue "threads" appear on the GPS display connecting the sea regions? I've not seen this with other multipolygons, so I'm wondering if this is also a symptom of problems.
CG> No, this is part of the multipolygon code. It connects the inner and CG> outer polygons with two lines, and the coordinates of the "returning" CG> line are move by one map unit. There is a comment in the code stating CG> that this results in "triangles" but that it is necessary or some CG> "inner" polygons are not rendered at all. I must admit that I don't CG> really understand how polygons with "holes" should be coded in the IMG CG> file.
Okay, that's reassuring to know. It's a separate issue that can be dealt with independently.
Quoting Toby Speight <T.M.Speight.90@cantab.net>:
I could give you the full areas.list (I don't know whether you can make splitter create a single tile) - but - I'm experimenting with cutting out smaller extracts using osmosis, to see whether I can produce a smaller file that still triggers the problem.
Splitter will happily create a single tile if that's what you tell it to do with an areas.list file. It will, however, still have to process the whole input file so it's not particularly quicker.
I did manage to reproduce it by extracting just the coastline from great_britain.osm:
/-------- | osmosis --read-xml $< --way-key-value keyValueList='natural.coastline' --used-node --write-xml $@ \-------- You could also do this crafting a custom XAPI call to www.informationfreeway.org (see emails passim on this list).
This gives a file containing only the coastline, which can be processed without splitting. And, for me, this exhibits the inversion. It does take quite a while to run through mkgmap, unfortunately (an hour of CPU time for me), so I'm looking at cutting it down to process smaller groups of islands. I might not get it done today, though, and I'm about to go off-line for a few days (back around the middle of next week). Interesting that you got this to work - I tried on a file which just contained the UK coastline and nothing happened for four hours, so I killed the process.
-- Charlie
0> In article <20091028090135.5xnc2gt9ytc0w880@webmail.cferrero.net>, 0> charlie <URL:mailto:charlie@cferrero.net> ("Charlie") wrote: Charlie> Interesting that you got this to work - I tried on a file which Charlie> just contained the UK coastline and nothing happened for four Charlie> hours, so I killed the process. Maybe my machine is beefier - 2.4GHz Core-2 quad, with 6GB of pretty fast RAM. Which is another good reason for me to try and slim down to a smaller extract that still exhibits the problem.
On Wed, Oct 28, 2009 at 08:54:09AM +0000, Toby Speight wrote:
CG> Are there really inland seas using natural=shoreline instead of CG> natural=water?
I've no idea - not in my region, I would think, but perhaps the Dead Sea? Let's not worry about this for now!
I have come across to some large seas in Finland that have been drawn with natural=coastline, as non-closed segments. This makes sense if you think of the lake Saimaa, for instance. If we manage to get the sea polygons to work for Finland ("the country of thousands of seas"), then anything should be possible. Best regards, Marko
Hi, does anybody know why the output of splitter is not recognized by JOSM? Is there a way to make splitter produce outputs that are compatible to normal .osm files like the ones downloaded by geofabrik? I would really like to use splitter to cut a country into managable chunks for offline editing in JOSM. Or wouldn't this work of other reasons I don't know yet? Thanks, Stefan
On Wed, Oct 28, 2009 at 10:45 AM, <stefan@binaervarianz.de> wrote:
Hi,
does anybody know why the output of splitter is not recognized by JOSM?
Is there a way to make splitter produce outputs that are compatible to normal .osm files like the ones downloaded by geofabrik?
I would really like to use splitter to cut a country into managable chunks for offline editing in JOSM. Or wouldn't this work of other reasons I don't know yet?
You should use osmosis for splitting up files for editing, not mkgmap's splitter. The mkgmap splitter is designed to split up data for Garmin map generation, not editing (and it may damage it).
Quoting stefan@binaervarianz.de:
Hi,
does anybody know why the output of splitter is not recognized by JOSM?
Is there a way to make splitter produce outputs that are compatible to normal .osm files like the ones downloaded by geofabrik?
I would really like to use splitter to cut a country into managable chunks for offline editing in JOSM. Or wouldn't this work of other reasons I don't know yet?
Thanks,
Stefan _________ Stefan,
I have successfully used splitter to create small areas for editing in JOSM. What is the error you are getting? If the data file is too big you will need to run JOSM with the -Xmx command to reserve additional memory. Charlie
On Wed, Oct 28, 2009 at 11:45 AM, <stefan@binaervarianz.de> wrote:
does anybody know why the output of splitter is not recognized by JOSM?
The last time I tried this, with a recent version of JOSM, JOSM rejected the splitter file due to an incompatible OSM API version. I haven't tried it, but I assume that this has to do with the <osm> element at the beginning of the file. Files downloaded with JOSM look like this: <osm version='0.6' generator='JOSM'> You could try changing the same line in the splitter file as above, to see if this will work. Cheers.
participants (8)
-
charlie＠cferrero.net -
Christian Gawron -
Christian Gawron -
Clinton Gladstone -
Marko Mäkelä -
stefan＠binaervarianz.de -
Toby Speight -
Ævar Arnfjörð Bjarmason