Felix,
Thanks for that patch... It does remove the bug, but all relations seem
to get dropped by using this patch too. So not an ideal solution -:)
BTW before using this patch, relations like cycleroutes would even show
up when all ways were dropped due to multipolygon outer...
OK - try
Hi Felix,
Yip, that patch works great. (using only this patch, without the earlier
patch; if I add earlier patch too I loose the relations again)
Yes, it replaces the earlier patch.
Good.
I am tempted to commit this - does anyone think that preserving the
original ways is a bad idea? If
Hi,
I'm trying to understand how the --generate-sea stuff works. I want to
know how it decides whether an island is water or land. The code does
not really contain sufficient comments for me to work out what it's
doing. I would expect it to close coastline segments that reach the
tile boundary
Hello Felix,
Is there a reason for not committing the patch? It is working great for
me and also Steve found it good
It has some good aspects but it also (as I think Steve mentioned) has
the downside of causing the sea polygon to be preserved so everything
ends up sea colour. As the
Hello Charlie,
Hurrah! Does this also mean that, with suitable definition of the
polygon used for land, we can finally banish the Garmin yellow
background to history?
Yes (and no).
You can give the land polygon whatever colour you desire.
However, at the moment, the patch doesn't
Hi Ralf,
My Nuvi 255T does show the white background using my topo map.
My 255W ignores any colour change on the 0x4b polygon.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
v3 - generate land poly even if tile doesn't contain any sea (when
--generate-sea=no-mp is specified) so that GPS units that ignore the
colour of the background poly (0x4b) don't the wrong background colour.
-
v2 - avoid generating sea poly when unclipped tile contains coastline
but the
Hi Bennie,
Thanks for the kind words.
I attach the TYP file I am currently using. It's very simple, I think
most people use more complicated files than that.
I also attach the style files. They are fairly similar to the default
files with a few tweaked values here and there. The seamark
Hi Manning,
Thanks! My archipelago is now OK.
Great, can you post a sample picture?
In my style file I added this:
natural=land [0x27 resolution 10]
in the typ file draw priority:
0x32 = 1
0x27 = 2
all others = 3 and up
Very good - I did not know that 0x27 was land, it's not listed
Hi Charlie,
I see you've got lots of placeholder polygons in your TYP file. Do you
know what these are / what they do / why one might want to use them?
If you use a TYP file, then you require either a polygon definition or
a placeholder for every type of polygon that you want in the map.
Have you tried setting the polygon 0x10d Basemap coverage area
(background) to white, too?
Don't think I have, will try sometime.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Felix,
It worked in 12/13 tiles. See below the broken tile where no 0x10f1d
polygon for the sea (as defined in polygons file) got created at all,
furthermore 1 island is flooded (in the center of the tile). I used grey
as backround color so one can easily spot mistakes.
From my meagre
PS - try no-sea-sectors - e.g. --generate-sea=polygons,no-sea-sectors
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
PS - try no-sea-sectors - e.g. --generate-sea=polygons,no-sea-sectors
Well if I use that option then I get the whole tile flooded.
As I said before: If you don't clip the coast, expect toast!
The good thing is, the --generate-sea option only adds about 7-8% of
generation
Felix,
Okay, so manual coastlines are probably still needed except for very
large extracts or islands.
Don't know what you mean by manual coastlines - the whole map is
manual, isn't it?
BTW it would be better to have mkgmap=land or similar, instead of
natural=land because natural=land
Hi Steve,
I've no idea, I've been wondering too. It could be that the way Mark is
doing the sea/island polygons is the right way, except that if I'm not
mistaken his method only works with a TYP file, whereas it is clearly
possible to do this without since the MetroEurope maps don't have
Charlie,
So why have a placeholder when you could just put in a polygon definition?
Good question - the placeholder simply gives the polygon's draw
priority, the style for that polygon will be whatever default the
GPS/mapsource uses. When you provide a full definition, you specify the
visual
Hi Nakor,
Mark, I am not familiar with TYP files, but if you provide me a sample
with all the files you submit to mkgmap, the command line and which
files should be included in the install I will be glad to improve the
NSIS file generation.
If you give the --index option mkgmap generates
Hi Steve,
It will include the index files if --index is given. Of course this
also generates the index too and it might be good to be able to build
from a previously generated set of files.
Hmm, I'm specifying --index but it's not putting anything into
osmmap.nsi that's related to MDR or
Steve,
Thanks, I will give it a go.
No sooner said than done. 2 issues observed in osmmap.nsi:
1 - the WriteRegStr line for the TYP file includes the TYP file's path
when it should be stripped? i.e.
WriteRegStr HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} TYP
Steve,
Thanks, I will give it a go.
1 - the WriteRegStr line for the TYP file includes the TYP file's path
when it should be stripped? i.e.
Would giving an arbitary Unix path even work in a windows installer?
Well, the problem would be the same if you were running it under
windows.
Hi Steve,
New patch attached.
Thanks, giving it a go... looks good.
Ah, just noticed that it doesn't put a line in the script to delete the
TYP file on uninstall - otherwise, looking good.
Cheers,
Mark
___
mkgmap-dev mailing list
Hi,
If anyone cares to test the installer for the demo Baltic map, I have
uploaded it to a temporary location:
http://www.smartavionics.com/download/OSM-Baltic.exe
It's not huge, about 30MB.
The family ID is 909.
I haven't made any attempt to distinguish the country names in the map
so as it
Hi Christian,
the installer works fine for me (Mapsource running on Windows XP Tablet
Edition).
Thanks for testing it.
Just one remark: The map shows as OSM Map - it would be easier to find
it if it would set a less generic name.
Good idea, I will change that.
Cheers,
Mark
Hi Steve,
Thanks for the report.
It installed all right on a Vista laptop.
Good.
Looks great, took me a long time to find any marine features though...
Yeah, the marine mappers (Open Sea Dogs?) have quite a lot of
work to do. Still, now they know that they can actually make usable
maps it
Hello Felix,
This setting was once really useful.
Now it is hardcoded into mkgmap to set all transport types except bus
and emergency to no. Could this please be reversed
Actually, no. That's because the carpoolness of a way is specified by
having all of the access bits except for
Hi Ralf,
The command line:
/usr/java/jre1.6.0_16/bin/java -jar mkgmap-r1455/mkgmap.jar --latin1
--family-id=1331 --product-id=1 --style-file=mkgmap-style-topotest/
--tdbfile=yes --remove-short-arcs 1040.osm.gz
Enable assertions - that may catch some overflow or other problem that
is
Hi Steve,
I think I have found the problem in Tags.java that was causing the
assertion when I tried to delete multiple tags. I believe the root
cause was the fact that remove() would decrement size so it looked as
if there was space but it didn't actually remove the key (as the
comment there
Using this patch, I am seeing better than 20% speed improvement when
processing the Baltic map. YMMV. The amount of speed up is dependent
on the density of tags. If your nodes/way are heavily tagged, you
will see a speed benefit with this patch. It will also reduce VM
required (I don't have any
Hi Steve,
Anyway, please check the attached patch for sanity ...
Looks good to me. Thanks, will now finally gain the benefit of not
wasting gobs of memory in the hash maps!
OK - now committed.
It's just a stroke of luck that I stumbled across these issues, if I
hadn't tried to delete a
Hello WanMil,
I am thinking about how to close polygons that are clipped by the
bounding box of the OSM file and are therefore not complete and not
closed? At the moment these ways are not handled by multipolygon code in
the mp branch. This causes lots of areas to disappear next to the
Hi Stefan,
in the archive (september 2009) I saw that there were some discussion about
inter tile routing problems. I use version 1445 and have the same problem
when doing a routing in Mapsource over 4 interceptions. 3 interceptions
working fine.
Are there some news about that issue?
I
Hi Charlie,
Firstly, Mark, many thanks for working on the sea polygon issue.
You're welcome.
I've found two problems with --generate-sea. One is relatively minor,
the other a bit more of a problem.
1 (minor). If you use an options file via the mgkmap -c switch, the
comma separated
Hi Chris,
Hi,
Why is this bollard not working? (car/shortest mode in MapSource)
http://up.picr.de/3573513.png
While another bollard near the church
(Mauritiusstraße) works fine ?
In my points-style I have:
highway=bollard | barrier=bollard {add motorcar=no} [0x7001 resolution 24]
Hi Felix,
set TRE 0-4-23 and it might work.
Err, sorry to be thick but where is this set?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Marko,
Will this discard boundary=administrative from islands completely,
or only from mkgmap polygon objects, and keep the tags on line objects?
The coastlines of large islands sometimes are administrative boundaries,
and these are translated by the default style.
Hmm, on reflection,
Can someone please either explain or point me at some doc that explains
the meaning of the splitter --resolution option:
--resolution The resolution of the overview map to be produced by mkgmap.
Default is 13
Does this force the tile boundaries to be rounded (not round in
shape, but
Is there a workaround to make that look better? Perhaps another
generate-sea option?
You could try generate-sea=polygons but note that you then need a rule
in your polygons file to generate a land polygon. e.g.
natural=land [0x010100 resolution 12]
and a corresponding polygon defined in
I forgot to say, that for a quick test you could use an existing
polygon type for the land polygons. The map would look weird but at
least you could quickly tell if the land/sea interface is good.
Cheers,
Mark
___
mkgmap-dev mailing list
Thinking some more about what I was seeing in mapsource when mousing
around the Baltic map, I came to the conclusion that the edges of the
overview map bounding boxes where in the wrong place so I took a look
at mkgmap where it rounds those coords and came up with the attached
fix. No great
Back in the Baltic...
When I split my map, the outside edge is ragged, i.e. the tiles that
reach the edge of the overall map don't finish at the same lat/lon. So
having split the map, I then have to manually edit the kml file and
tweak the coordinates for the outside edges to make them neat and
Hi Chris,
I'm curious as to why you want this. I added the tile trimming as a feature
back in September as a result of a suggestion from Steve and I wasn't aware
there was any downside to it:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/004080.html (note the
first link no
Hi Felix,
On 16.01.2010 13:48, Mark Burton wrote:
Hi Chris,
I'm curious as to why you want this. I added the tile trimming as a feature
back in September as a result of a suggestion from Steve and I wasn't aware
there was any downside to it:
http://www.mkgmap.org.uk
Hi Chris,
Here's the start of the thread that led to the addition of the --resolution
parameter:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/003295.html
But basically yes you're right, --resolution forces the tiles to be rounded
to particular boundaries. If you manually
This patch stops the DP filter from discarding points at either end of
a horizontal or vertical line segment (such segments are created by the
clipper and also by the polygon splitter and, of course, could occur
naturally in the OSM data but I'd guess they are relatively rare).
The benefit is
While, we're in the Baltic, I should tell you this:
Markus sent me a sample of the Baltic map that had been created by
someone else by converting from OSM to MP and then processing it with
cgpsmapper. It looks nice but one thing I noticed is that the redraw
speed (in mapsource) is terrible. For
Hi WanMil,
The attached patch contains a merge from the mp branch and fixes lots of
multipolygon issues.
I have also added some more javadoc and code comments, renamed methods
and variables and removed not very useful logging statements.
The mp branch is no longer needed.
I tried
Yeah, the islands are not bad but the main land masses are all flooded.
There's a lot of spurious crap when you zoom out but that (almost
completely) goes away if you use the patch I posted earlier this
evening.
Mark
___
mkgmap-dev mailing list
WanMil,
I will try to reproduce your errors and to improve the error messages.
I wasn't complaining about the quality of the messages, merely telling
you that they were happening.
Which dump do you use for your Baltic map?
I grabbed it with XAPI (a mistake as it was about 2GB uncompressed)
Hi WanMil,
I get these errors when compiling with that patch:
[javac]
/home/markb/OSM/mkgmap-git-svn/src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java:1065:
cannot find symbol
[javac] symbol : method isLoggable(java.util.logging.Level)
[javac] location: class
Hello Johann,
I have not tested this patch. I expect it to work, but I think it is a
suboptimal solution.
I make no claims that it is optimal. Merely, that it's cheap and
cheerful. It achieves the desired aim with very little computational
overhead.
You set the preserve bit on all lines
Hi Chris,
I've just checked in some changes that adds a --no-trim parameter to the
splitter to disable the trimming of empty areas around the edges of tiles.
I will give it a go.
Thanks,
Mark
___
mkgmap-dev mailing list
Hi WanMil,
The v3 patch is working well with the Baltic map. The main land masses
are there and I haven't yet spotted any missing islands.
One issue, the boundaries of the tiles are visible on the land at all
zoom levels (see visible-tile-boundaries.png). The boundaries are not
visible on the
WanMil,
My workaround was based on the assumption that all polygons created by
the mp code will be clipped to the bounding box later (by the style
code). Can you confirm that?
Yes, polys are clipped in StyledConverter.addShape().
I looked at the output using mapedit and the land has no
WanMil,
Good news - I don't think it's your problem. I disabled the sea
generation completely and the lines on the tile edges are still there.
Haven't a clue what's causing them (and I don't care because they don't
show up when I use generate-sea=polygons).
One issue that I don't think you can
WanMil,
Good news - I don't think it's your problem. I disabled the sea
generation completely and the lines on the tile edges are still there.
Oops, I may have spoken too soon. With your v3 patch in place, I made a
new map with generate-sea=polygons and not only are the lines still
there, all
Hi Ronny,
this patch (against 1485) adds a new option for generate-sea:
extend-sea-sectors
If this option is set, coastlines not reaching the borders of a map will
be extended with a point at the nearest border.
This prevents strange things happening at the borders of geofabrik extracts.
Hi Felix,
I just tried out this patch on Italy from geofabrik (on trunk plus
wanmil's mp patch v3) and it was the first time for me that I got a
correct sea generation (using
--generate-sea=polygons,no-sea-sectors,extend-sea-sectors),
(well the sea was empty so I had to color 0x4b
Hi Ronny,
OK. I added some comments. Hope this explains what is done.
Thanks for that quick response.
Felix has already tested your patch and is getting good results so it
looks good for committing.
Mark
___
mkgmap-dev mailing list
Ronny,
Sorry, I missed this before. Could you please add a line to the
generate-sea help blurb that describes the new option and also
add similar words in the appropriate place in resources/help/en/options.
Thanks,
Mark
___
mkgmap-dev mailing list
Felix,
Ups, just noticed that that once I zoom in to closer than 3km in Italy
everything is flooded (in Denmark there is no problem) as 0x10100 is not
set on resolution 24-20 (only 17-19) ( when using
--generate-sea=polygons,no-sea-sectors,extend-sea-sectors option and
then setting
[duplicate message, original got lost?]
Hi Felix,
Okay, on maps in the northern hemisphere without patch no problem. In
maps of the southern hemisphere with and without patch I loose the
tooltip for a small stretch.
OK, thanks.
That's quite different from what I get here on my GB map
Felix,
Maybe it would be best to find out why the overview map does not fit if
created with mkgmap. If I use maptk it fits 100%.
What resolution is the overview map created by maptk? mkgmap uses 13.
Mark
___
mkgmap-dev mailing list
Felix,
Which file is this supposed to be in?
Osm5x...
Well if it works, I think you should submit this patch, the mp patches
and the extend-sea patches into trunk. It all seems to work very well.
Ideally, WanMill will add that change to his MP code and then issue a
new patch that can
This is just a rework of my earlier patch with the filter class renamed
so that there can be no doubt as to what it does.
As before, the rational behind this is to stop the DP filter from
deleting the end points of lines that have been introduced by either
the clipper or the polygon splitter
Hi Steve,
On 18/01/10 18:05, WanMil wrote:
Attached patch (against the mp branch) solves this.
OK thanks, applied.
Is everyone happy that this is now a big improvement over trunk?
It's performed well when processing the Baltic map.
One thought, and I may be completely wrong here
Felix,
Please put the extend-sea patch also into the branch...
I am hoping that Ronny will provide a new version that includes the
missing help blurb.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Steve,
Hi
I have a map of the UK with sea (using --generate-sea=extend-sea-sectors)
This is much better than the last time I tried as it was faster and
there is no flooded land.
I do get a lot of horizontal and vertical artefacts when zoomed out
that go away when I zoom in.
I
Steve,
Oh OK, I've attached a picture of the worst bit - that is expected then?
Hmm, that's particularly bad, attached is what I get when using
multipolygon (and my h v patch). As you can see, not bad at all.
Zooming in and out doesn't make it change very much.
I took another look at the NZ
Actually, I'm really impressed that the mp code can handle that tile at
all in a reasonable time.
It's interesting to look at it in mapedit. You can see exactly how the
sea has been split to fit around the islands.
FYI mapedit reports over 16000 sea polys for that tile. By comparison,
if I use
Steve,
Does this splitting happen at the generate sea stage or is it
being mangled later on?
It's done by the new mp code.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hello Carlos,
Since yesterday the number of similar arcs warnings has increased very
much, but when you look at the supposed wrong data, they are correct and
there are no recent changes. May be recent commits have introduced some
bug in this regard. You can have a look at this one for
Hi Carlos,
OK, I see. It's due to bridges I have introduced recently in my maps. In
some of my attempts to get bridges working I had to add road_class and
road_speed to the bridges lines. I suppose removing them will solve the
problem, won't it?
Yes, adding class or speed makes a way into a
This patch modifies the turn heading adjustment code so that the GPS
will tell you to turn when you are routing from a main road to a side
road in situations like this:
S
S ^
S |
MM |
M |
M |
Hello Felix,
The biggest problem is that after changing around, I thought it all
works well and did not do any backups of how my style-file worked before
until realising the mess. 1498 and upwards if !=* is not working 100%
correct, is simply unusable. This was a real degradation. Now I
The attached patch adds the OSM source file name into log messages so
if you are processing multiple files, you know which file each message
relates to.
The file name (plus a ':' suffix) is inserted between the message
type/class and the message itself.
Please test, especially if using multiple
Hi Steve,
There is a ThreadLocal class specially for keeping values on a per-thead
basis, as in the attached modification to your patch.
Thanks, I was not aware of that class.
With your code there is a slight chance that there will be a problem if
a value is set at exactly the same time
Apart from Felix's report, I have seen no other comments about this
patch so I shall commit it unless anyone reports any problems with it
in the next day or so.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hello Charlie,
The patch seems to work fine, insofar as it doesn't make anything break,
but I can't seem to find any candidate junctions where the effect of the
patch is obvious.
OK - thanks for the report.
Anyone else tried this? If so, was it good/bad/the same/didn't
notice/don't
Felix,
Could you try to find out what goes wrong in my map?
The very small osm file is here (style and levels don't seem to matter):
http://openmtbmap.x-nation.de/maps/legend.zip
What's going wrong? I tried making it with my default style and could
see various lines/area/pois OK.
Mark
Here's something from last year that I forgot to push out.
I noticed that a RGM (Real Garmin Map) only contained a single
background rectangle (0x4b) for each layer. i.e. the rectangle was not
split like normal polys are. The attached patch makes our maps the same
so you just get one 0x4b poly
Felix,
If you're referring to the fact that the overview map does not match
the bounding box of the map itself, that's because the tile's bounds
are not rounded in the same way as the overview bounding box (lons
rounded down, lats rounded up (at zoom level 13?))
Well that is
v1 + v1 - OK, here's the matched pair - patches for both the splitter
and mkgmap.
With these in place, the mapsource mouse works as expected across all
tile boundaries right up to the outer boundaries. No weird overlap
of tile and overview map. Spot on.
Please could some others give this a test
Hi Chris,
I've just checked in some changes that adds a --no-trim parameter to the
splitter to disable the trimming of empty areas around the edges of tiles.
Just got around to using the --no-trim option - worked as expected.
Thanks,
Mark
___
Felix,
So we need the splitter even if the tile needs no splitting. Correct?
Maybe my problems with the legend map relate to me not passing it trough
the splitter. Will try out if it makes a difference.
A side effect of using the splitter is that it rounds the boundaries of
the tiles.
So
Felix,
The fix to the splitter plus the patches DID it. However why is the map
flooded if I don't put an natural=land all around it. I'm using =polygons
Have you got any idea on this?
I should think that your little natural=coastline poly on the RHS just
below the middle is causing the
This patch extends the sea generation stuff to cope with anti-islands
(water inside, land outside and, presumably, where the anti-treasure
is hidden). Anti-islands are tagged natural=water (you can't use
natural=sea because it will be beneath the surrounding land polygon).
Note that if your map
Felix,
Does not work 100% for me yet, but in principle it seems to work.
--generate-sea=polygons,extend-sea-sectors,close-gaps=1000
Square tagged with
natural=coastline
a) direction of way: anticlockwise == Correctly map is flooded,
inside is dry
Good.
b) direction of way:
v2 - now checks to see if an anti-island is surrounded by water or land.
If surrounded by water, it is converted back into an island (tagged
with the land tag) and a warning message is issued.
Tested with the GB map, it detected a handful of anti-islands that
should have been islands but their
Hello Marko,
I tested with the FI map, but did not get any anti-island warnings.
I tested both without and with --generate-sea=polygons. Sorry,
I did not run --generate-sea=polygons without your patch. With
generate-sea, I found some anti-treasure like the following.
2010/01/26 22:41:52
Marko,
Yes, it goes away if I don't generate sea. I reran --generate-sea=polygons
without your anti-island patch:
2010/01/26 23:26:58 WARNING (Osm5XmlHandler): Way null
(http://www.openstreetmap.org/browse/way/4611686018427418078) has consecutive
nodes with the same coordinates
Hi Clinton,
I've been testing a map compiled with this patch for the past couple of days.
Since I don't have a good test case, I was not able to notice any large
differences. It seemed to me that the Nuvi was a bit more talkative than
usual, but that could be my imagination.
The patch
Marko,
2010/01/26 23:26:58 WARNING (Osm5XmlHandler): Way null
(http://www.openstreetmap.org/browse/way/4611686018427418078) has
consecutive nodes with the same coordinates
(http://www.openstreetmap.org/?mlat=62.22656mlon=25.82736zoom=17) but
they can't be merged because both are
Hi Marko,
Please try the attached patch and see if it gets rid of the can't be
merged error you are getting when generating sea.
Mark
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index b90fda1..d6cacab
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
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
Hi Marko,
Please try the attached patch and see if it gets rid of the can't be
merged error you are getting when generating sea.
Sorry, no dice. I still see several of the warnings, including the one
that I reported last night:
2010/01/27 23:40:12 WARNING (Osm5XmlHandler): Way null
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
Hi Marko,
Here's another cut at a fix for the warning you were getting. If you
have time, please try this patch without the other patch I posted
earlier today (the one that got rid of the warning by allowing the
merge to be done).
If successful, I intend to commit both this patch and the one
Hello Christoph,
At the moment I try to make some garmin maps for haiti with mkgmap.
I use the geofabrik-extrakt of Haiti:
http://labs.geofabrik.de/haiti/latest.osm.bz2
OK - just grabbed that.
The Problem is, that I am not able to make the damn sea blue!
I used
401 - 500 of 644 matches
Mail list logo
