Support for seamark tags in default style
Hi Marko, I haven't changed the seamark style stuff for a while now so I wonder if the attached rules could be incorporated into the default style so that anyone can generate maps with lights & buoys, etc. Mark PS - did you try the patch I posted yesterday to fix the error messages you were seeing when generating sea?
Hi Mark, On Wed, Jan 27, 2010 at 09:36:06PM +0000, Mark Burton wrote:
Hi Marko,
I haven't changed the seamark style stuff for a while now so I wonder if the attached rules could be incorporated into the default style so that anyone can generate maps with lights & buoys, etc.
I wonder if the seamark stuff could be a style on its own and resources/styles/default/info could say: base-style: seamark That would allow someone to build seamarks on a separate map layer without cherry-picking definitions from the default style. On a related note, I wonder if the default style could be split to several substyles. Currently, StyleInfo allows at most one base style.
PS - did you try the patch I posted yesterday to fix the error messages you were seeing when generating sea?
Sorry, I was busy with something else. Coincidentally, I did it while you were asking. :-) Sorry, your patch did not remove the messages. Marko
Marko,
I wonder if the seamark stuff could be a style on its own and resources/styles/default/info could say:
base-style: seamark
That would allow someone to build seamarks on a separate map layer without cherry-picking definitions from the default style.
Err, I've never heard of base-style. If it does what I think it would do, that would be fine. So we could have a "marine" style that has the rules I sent to you but then goes on to include all the default stuff? How do you specify which style to be used? Mark
Hi Marko,
Sorry, I was busy with something else. Coincidentally, I did it while you were asking. :-) Sorry, your patch did not remove the messages.
Please try the attached new patch. I can guarantee that that message will go away now because I removed the message! Hopefully, the coastline will be OK too. Mark
Hi Mark, On Wed, Jan 27, 2010 at 10:45:43PM +0000, Mark Burton wrote:
Please try the attached new patch.
I can guarantee that that message will go away now because I removed the message!
Hopefully, the coastline will be OK too.
The patch that you attached is apparently included in your recent commit burst (r1533; patch -Rp1 applied without conflicts). I am still seeing it with unpatched r1533 (if we ignore the traffic_calming=* that I added to the points file): 2010/01/27 23:40:12 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427418010) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes! There are lots of other warnings for mlat=62.22656, because it is the tile border and there are many lakes around that latitude. (The district around Jyväskylä is sometimes called the Lake-Finland (Järvi-Suomi). I could probably reduce the amount of these warnings by moving the tile border further to the south, but I would like to have mkgmap fixed. I am also seeing many of these: 2010/01/27 23:40:08 WARNING (Osm5XmlHandler): Non-closed coastline segment does not hit bounding box: 279763707 (61,81651/30,07776) 279763719 (61,81599/30,07524) http://www.openstreetmap.org/?mlat=61.81651&mlon=30.07776&zoom=17 but they can most likely be attributed to Geofabrik's cutting (Finland is about 60N,20E to 70N,30E). Has someone already bugged the osmosis or Geofabrik folks about this? Could I work around the issue with some mkgmap options? I guess I'd want an imaginary L-shaped coastline running south from the Swedish-Finnish border and turning east towards St. Petersburg. Marko
Hi Marko,
I am still seeing it with unpatched r1533 (if we ignore the traffic_calming=* that I added to the points file):
2010/01/27 23:40:12 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427418010) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes!
Err, that message is not in r1533 - something's screwy!
2010/01/27 23:40:08 WARNING (Osm5XmlHandler): Non-closed coastline segment does not hit bounding box: 279763707 (61,81651/30,07776) 279763719 (61,81599/30,07524) http://www.openstreetmap.org/?mlat=61.81651&mlon=30.07776&zoom=17
but they can most likely be attributed to Geofabrik's cutting (Finland is about 60N,20E to 70N,30E). Has someone already bugged the osmosis or Geofabrik folks about this? Could I work around the issue with some mkgmap options? I guess I'd want an imaginary L-shaped coastline running south from the Swedish-Finnish border and turning east towards St. Petersburg.
Have you tried the close-gaps option to generate-sea? That may help: close-gaps=NUM close gaps in coastline that are less than this distance (metres) Mark
Hi Mark,
Err, that message is not in r1533 - something's screwy!
Sorry for the noise then. I did "ant clean; ant dist" now. I wonder if something is broken in ant's or javac's dependency detector. By the way, --generate-sea complains, even though the help blurb says that multipolygon should be the default.
Have you tried the close-gaps option to generate-sea? That may help:
close-gaps=NUM close gaps in coastline that are less than this distance (metres)
I just launched --generate-sea=multipolygon,close-gaps=1000. Let's see what happens. I will also run with --generate-sea=polygons to see if the flooding persists. Marko
Hi Mark, WanMil, On Thu, Jan 28, 2010 at 10:53:33PM +0200, Marko Mäkelä wrote:
Hi Mark,
Err, that message is not in r1533 - something's screwy!
Sorry for the noise then. I did "ant clean; ant dist" now. I wonder if something is broken in ant's or javac's dependency detector.
Oh, now I got it: I was grepping an old log file. I forgot -Dlog.config=logging.properties today. (I was lazy and did not run my osm2img.sh script. I was even too lazy to copy&paste the command, and typed it from memory. I was reusing the tiles from yesterday.) Sorry, it is too late for me now to rerun to get updated log messages. For what it is worth, I am seeing a similar general flooding for the southern part of Finland with generate-sea=multipolygon,close-gaps=1000 as with generate-sea=polygons. Land and sea are inverted south of lat=60.50997 (approximate, from the GPS unit when running with generate-sea=multipolygon). With multipolygon,close-gaps the middle tile (north of Jyväskylä) is not flooded. I am even seeing a nice multipolygon (island on the Baltic sea) at lat=65.01658 lon=24.87991, Hailuoto, west of Oulu. But the Baltic sea has a sharp SW corner there. The sea ends too early in the west before the Swedish/Finnish border but also in the south. There is no sea at much of the west coast. This could be due to Geofabrik's cutting. At http://www.openstreetmap.org/?mlat=61.87505&mlon=27.88302&zoom=14 I am seeing an island, but without a tooltip. I only see the tooltip "Järvi" (lake) when I hover to the coastline around the island. Could this be because the island is just background? Same for the small island north of this one. The islands on the coast of Helsinki should be mapped well, but unfortunately they are within the inverted land/sea area. :-( In conclusion, I am getting slightly better results with generate-sea=multipolygon, but both generate-sea options seem to be suffering from the inverted land-and-sea near the west and south coasts. It is as if there map is XORed with a few rectangles, if you think yellow=1 and blue=0. Best regards, Marko
In conclusion, I am getting slightly better results with generate-sea=multipolygon, but both generate-sea options seem to be suffering from the inverted land-and-sea near the west and south coasts. It is as if there map is XORed with a few rectangles, if you think yellow=1 and blue=0.
Yeah, I have seen this also in some previous runs. Tomorrow I will compile finnland with my GPX analysis. This stores all ways processed by the multipolyon code as GPX files which is very good for analysis. I think then I can say more where the problems are. WanMil
participants (3)
-
Mark Burton -
Marko Mäkelä -
WanMil