Alternatively, you can use my coastline extracts:
http://fabianowski.eu/osm/coastlines/
They are not precompiled coastline files but coastlines extracted from
the planet file and the Geofabrik Europe file. You can feed them to
mkgmap directly.
I update the files as time permits. The most recent
I have never looked at how the precompiled coastlines work. Maybe my
extracted coastlines will remain useful in many cases after all. If so,
I am happy to keep providing them. One advantage the extracted files
definitely have is that I am updating them every day, based on the
current Geofabrik
You can always use my daily updated coastlines as well. These are based
on the Geofabrik Europe extract respectively the complete planet file,
so they will be more complete than the coastlines you get from a
single-country extract:
http://fabianowski.eu/osm/coastlines/
- Bartosz
Glad I could help. The coastline files will definitely keep getting
generated day by day. They will just move to our company site somewhere
underneath dobini.com one day. But I will put in a redirect once that
happens.
- Bartosz
___
mkgmap-dev
As it is, it *seems* to realise that the coastline file is as I'd
flagged it, but then reports that it can't read such a file.
Confusing.
That is rather silly behavior indeed :).
P.S: I can now confirm that Bartosz's fix (specifying a separate
coastline file) appears to have completely
Following the coastline to check whether it enters the current tile
again will work in Great Britain but may fail in continental Europe. The
Geofabrik Europe extract does not have a closed coastline after all.
That would have to go all around Asia and back. So yes, following the
coastline out
Notice that once you've done the miserable tour of Asia once, then it's
OK to split the resulting Europe tile
Correct. So your idea would work but only if the extracts you begin with
have coastlines generated in the same way, by following the parts that
extend outside the tile boundaries.
If more than one point of the same tag exist the first one is used.
What if there are multiple entrances with different house numbers? This
is common in many countries with those huge communist blocks of flats.
- Bartosz
___
mkgmap-dev mailing list
You can try the following:
Download the European coastline file from [1] with the same time stamp
as your input pbf and pass it to mkgmap via the --coastlinefile option.
If this fixes the flooding, you are suffering from the same problem that
I keep running into - the coastline fails to reach
How did you pass the file to mkgmap? If the file is in the current
directory, the parameter should be:
--coastlinefile=coastlines_europe-111004.osm.pbf
- Bartosz
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Replying to myself, I think I see the problem now. You are specifying
paths relative to the current working directory while mkgmap searches
relative to its installation directory. Try specifying the coastline
file and the boundary directors as absolute paths.
- Bartosz
Therefore, I have been tagging the main entrance with the same tags as
the building polygon, replacing building=yes with building=entrance. Is
this really tagging for renderers?
I would say it is not tagging for the renderer but it is odd tagging
nonetheless. A building=entrance should be all
No problem. I have a batch job running that uploads fresh coastlines to
[1] every day. I will move this to our company webspace somewhere
underneath [2] eventually.
- Bartosz
[1] http://fabianowski.eu/osm/coastlines/
[2] http://labs.dobini.com/
___
Exact map coverage is (0.0,0.0) to
(2.1457672119140625E-5,2.1457672119140625E-5)
This bounding box is a whopping 5.7m² in size (in projected map units)
and lies at the intersection of zeroth meridian and equator. I suspect
there is very little data in that region... hence, osmosis is not
I was using the patch you had posted on 21st June so far and have tested
the new patch now. Both work equally well for me - no area to small
errors.
- Bartosz
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
geofabrik extracts are to blame - they're too tight in some places, so
the coastline breaks in the extraction process already
In a sense, this is true. However, *no* polygon can ever be guaranteed
to contain enough data. Even if Geofabrik used a bounding box instead of
a bounding polygon so
It still takes a little tweaking to get the coastlines right. I have
manually chosen the tile borders so that the coastline will end outside
the tile border. Only in the Swedish/Finnish border I am using
extend-sea-sectors to make up some coastline in Sweden.
This is why I collected the
I use my own polygon file to extract germany from the european extract.
It should be sufficient to extract coastlines using that larger polygon
only. Of course once you are extracting, you can just use your own
extracts throughout. But a combination of the Geofabrik extract for map
data and
2011/08/29 09:46:03 WARNING (Subdivision): 63240010.osm.pbf: Subdivision
width is 36627 at 3231057/1236133
I guess it is time to split my tile further. But, this is not the
biggest tile:
The Subdivision class is complaining about the width of an area in
Garmin units. The area may not
fixed tiles may produce better coastlines, but you'll get map too big
at some point as the map grows.
The way I understand Marko's suggestion, you would give the splitter an
initial list of tiles (or just a region) and it would then subdivide
that into smaller tiles as it does today. The
i'm starting to wonder if we're talking about 2 separate issues
Indeed, it seems so :).
1. they get broken in the extraction process because the poly is too tight
You mean the bounding polygon is so tight that it actually clips away
the coastlines? If so, the bounding polygon is simply
Wouldn't this mean that tile boundaries would overlap if they were
originally touching but not aligned?
Yes, you are right. The splitter code is not sufficiently documented to
make it clear what it is trying to achieve. After looking at the code,
it seemed to me that the goal was to expand
That's great. With this procedure I can use the german extract from
geofabrik without the missing sea near Emden.
You will still have to download all of Europe to extract the boundaries
for your larger polygon. Or alternatively you can use the extracted
boundaries I provided.
- Bartosz
First, you will have to download and process much more data than just
the country extract.
This is why I shared my extracted coastlines. The extraction has to be
done only once. Everyone else can just download the (relatively small)
coastline files.
Second, if the continent extract was
Thanks, that's one person interested in automatically updated
coastlines. I will watch the download logs over the next few days to see
whether I should start generating coastlines daily.
- Bartosz
___
mkgmap-dev mailing list
I have just uploaded today's coastlines_europe.osm.pbf. The time stamp
matches the europe.osm.pbf file that this was created from.
Right now, I still need to manually upload and fiddle with the
timestamps. I am switching to a better hosting setup in a couple of days
that will allow me to fully
But: Each time I have created these extracts I have found several
country borders that have been broken. So I repaired them before
creating the same stuff again and ensured that the boundary extracts
were uploaded only if the country information was complete.
I am happy to devote server
Maybe the overlap parameter of splitter prevented that because splitter
puts all points in the tile that is either contained in the bounding box
or contained in a overlap region with width overlap garmin units. If
overlap is larger than the expansion you don't see this problem.
I investigated
Hi list
I am debugging a coastline/sea generation issue and in the process of
this, discovered what I believe to be a splitter bug.
There is a method in RoundingUtils.java that rounds the boundaries of an
area to multiples of Garmin units. The minimum and maximum longitude are
both rounded
I keep seeing the following warning with current trunk (2018):
SEVERE (MapSplitter): 63240001.osm.pbf: Area too small to split at [...]
(reduce the density of points, length of lines, etc.)
I can confirm that the patch proposed in this thread still applies
cleanly and fixes these warnings.
Hi list
I spent the last 12 hours debugging sea generation problems in Europe.
After digging through a lot of mkgmap and splitter code, I believe I
understand the source of the issues now.
Since data is processed in tiles, the sea generator will often encounter
coastlines clipped at the tile
Hi list
I just made a map of Spain using the newest Geofabrik spain.osm.pbf and
mkgmap trunk. I set the default country to España. After loading the
map onto my Vista via MapSource, the following countries show up in
address search:
Es
España
France
Spain
The two in the middle are correct.
Since I stopped using is_in and openGeoDb in my style files my
problem on Belgium disappeared.
I am sure those problematic country name variants are being read from
is_in tags. So ignoring is_in will make them disappear. But I do want to
use is_in, at least for now, until there is a better
Hi list
I remember many discussions and comments about how mkgmap produces
Garmin's legacy format only and the NT format is still a mystery. Today,
I was pointed at a discussion of the Polish UMP project (similar to OSM,
strongly concentrated on Poland and surrounds). As I happen to be Polish
UMP maps do a primitive form of lane assist. The label at the top of the
nüvi screen changes from Some Street to Some Street (lane name) in
advance of a complex turn. That is all. No pretty pictures of junctions
and lanes:
http://ump.fuw.edu.pl/wiki/Asystent_Pasa_Ruchu
- Bartosz
This patch seems to work well, at least as far as Dermot and myself can
tell. Before the patch is forgotten and bitrots away, maybe it could be
committed?
- Bartosz
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
I just made a jar file with that patch and uploaded it at [1]. This
build additionally includes the patch posted by Steve a couple of days
ago that should fix address search.
- Bartosz
[1] http://www.fabianowski.eu/osm/mkgmap/mkgmap.jar
___
Yes, your patch works!
I just went through the test cases that used to break. All work now. I
then rebuilt a map of all of Italy. Address search works in that map as
well. It looks like the bug is fixed. Thanks a lot.
- Bartosz
___
mkgmap-dev mailing
The advice should probably have been to use 161 or newer. Once pbf
support was added, I do not see why it would disappear again in a later
version. I am using 170 and it has parsed any pbf I have thrown at it so
far.
- Bartosz
___
mkgmap-dev mailing
Perhaps its because in many countries refs begin with 'A' or 'B' and so
sort early anyway. (Not true in the USA though, so can't be the whole
reason).
I have done a lot of testing to try and isolate the bug as best as
possible. I was unable to break routing in Ireland - and there, refs
start
I have some further data points:
1. Changing ref=S6 to ref=A6 *does* make search work again. So if
the ref comes before the street name alphabetically, all is good.
2. I made a corresponding minimal extract of Dublin, Ireland. I found
that the same thing happens: If the single street has a ref
* If a street has a ref that comes after its name, alphabetically, it
can be found
* If a street has a ref that comes *before* its name, alphabetically,
the street is *not* found.
Argh, I got these two the wrong way around :(. The correct statements are:
* ref before name works
* ref after
I have further reduced the problematic map down to a tiny testcase. All
that is left is:
* A single city node providing location information to mkgmap
* A single road with two nodes
The road is called Demo Street and has a ref of S6. If I build a map
out of this data file and install it on my
First of all yes, the Legend is essentially a Vista without a barometer.
So they are very similar.
I applied your patch and regenerated the map of Italy. Search failed as
before. I then started over with a tiny extract of central Turin. For
this, search worked. I started increasing the
To follow up on my earlier post, I have tried running mkgmap again on a
full Geofabrik extract of Italy, split using splitter.jar with default
settings. Address search still fails:
I can select a country on my Vista and I do get proper behavior when
typing a city. But when I start typing a
Thanks for the tip. I removed --link-pois-to-ways and after that did
not help, tried removing --make-all-cycleways as well. I can see that
removing these options does change things as the map file becomes
smaller - but search still fails in the exact same way.
From what I understand about
Thanks for that. I did some further investigation together with Dermot,
another OSMer. Your map of Turin and my map of Italy behave in exactly
the same way: Address search works on an Oregon but fails on two
different Vista HCx devices.
So there is something in the maps that mkgmap produces
OFFTOPIC: I suggest to download the pbf-files.
Yes, of course. The use of osm.bz2 files is a legacy decision. I have
some mkgmap-related scripts that I wrote a long time ago and have not
updated yet. So to make sure I can use my data files with these, I am
sticking with osm.bz2 for now.
Now,
Hi list
I am trying to get address search going. It is almost working but not
quite. I have updated mkgmap to the newest trunk and am invoking it with:
java -ea -Xmx1536m -jar ../../mkgmap.jar \
--gmapsupp \
--description=Italia 19.03.2011 \
--countryname=Italia \
49 matches
Mail list logo
