On 03/18/2011 02:55 PM, Ralf Kleineisel wrote:
On 18.03.2011 14:45, WanMil wrote:
Yes, we provide the same option for coastlines. So it's possible
although there is the size restriction.
Boundaries take around 3% of the complete OSM data (3% as osm.gz
compared to osm.pbf). So think about
On Sun, Mar 20, Martin Simon wrote:
I think I read on this list before that in theory, polygon-shaped
tiles are no problem in garmin format.
At least garmin seems to do this for the City Navigator Maps for
Europe and Noth America. It would be really great if mkgmap could
create such maps, too.
Hi,
I did a test of the whole Benelux area plus border regions, splitted from the
europe extract, and found a lot of cities in the border areas that were
assigned to the wrong country. So I don't agree that admin_level=2 is working
fine.
I also observed a lot of elements that were not
Hi,
I did a test of the whole Benelux area plus border regions, splitted from the
europe extract, and found a lot of cities in the border areas that were
assigned to the wrong country. So I don't agree that admin_level=2 is working
fine.
Ok, it would work in case the algorithm is
Hi,
stupid question:
If the polygon points are sorted (i.e that area is always to the left side
of the border; anti clockwise orientation ), then the multi polygon
algorithm could know that solution 4 is incorrect.
Stefan
2011/3/17 WanMil wmgc...@web.de
I have a big problem to continue the
in general they are not sorted. only coastline ways are directional.
I don't think there is any algorithmic approach to solve this. the only
solution is to keep the whole relation in splitter or close the gaps in
splitter before throwing away the rest.
On 18 Mar 2011, at 7:43 , Stefan Schunck
Am 18.03.2011 14:45, schrieb WanMil:
Yes, we provide the same option for coastlines. So it's possible
although there is the size restriction.
Boundaries take around 3% of the complete OSM data (3% as osm.gz
compared to osm.pbf). So think about creating a europe map from the 4.5
GB dump. The
I have a big problem to continue the development on the locator branch.
I observed that a lot of admin_level boundaries (2,3,4,5 and sometimes
6,7,8,9,10,11) are not useable because they are not completely contained
in the tile data. The polygons are closed automatically but this is only
a
WanMil schrieb am 17.03.2011 21:12:
I observed that a lot of admin_level boundaries (2,3,4,5 and sometimes
6,7,8,9,10,11) are not useable because they are not completely contained
in the tile data. The polygons are closed automatically but this is only
a good guess in which direction they have
WanMil schrieb am 17.03.2011 21:12:
I observed that a lot of admin_level boundaries (2,3,4,5 and sometimes
6,7,8,9,10,11) are not useable because they are not completely contained
in the tile data. The polygons are closed automatically but this is only
a good guess in which direction they
And another requirement is also hard to achieve: performance. The branch
is not optimized very well yet. But I am sure that such searches for big
areas from all items of a tile are quite expensive no matter how
optimized they are.
WanMil
___
I
And another requirement is also hard to achieve: performance. The branch
is not optimized very well yet. But I am sure that such searches for big
areas from all items of a tile are quite expensive no matter how
optimized they are.
WanMil
___
I
Stupid question...
Why don't extract the boundaries with osmosis to a single file.
mkgmap could use this file to complete the boundaries while rendering the
maps...
Martin
Am 17.03.2011 um 22:57 schrieb WanMil:
And another requirement is also hard to achieve: performance. The branch
is
On 17.03.2011 22:57, WanMil wrote:
And another requirement is also hard to achieve: performance. The
branch
is not optimized very well yet. But I am sure that such searches for
big
areas from all items of a tile are quite expensive no matter how
optimized they are.
WanMil
I observed that a lot of admin_level boundaries (2,3,4,5 and sometimes
6,7,8,9,10,11) are not useable because they are not completely
contained in the tile data. The polygons are closed automatically but
this is only a good guess in which direction they have to be
closed. The
Hi Nakor,
the way http://www.openstreetmap.org/browse/way/34672931 is tagged
wrong. It is an inner way of a relation which means it is *not* tagged
with the relation tags. The way itself has no name tag and does not
belong to any boundary relation as *outer* way. So in the end the branch
Thanks Wanmil,
I tested a few tiles of the Benelux, and finally I found the street where I
live in the correct city, and not in a neighbourhood village anymore.
Congratulations, you have done a great job! :-)
For the Netherlands, streetnames assign to admin_level=10 or else (if not
specified)
Hi Minko,
Thanks Wanmil,
I tested a few tiles of the Benelux, and finally I found the street where I
live in the correct city, and not in a neighbourhood village anymore.
Congratulations, you have done a great job! :-)
Good news!
For the Netherlands, streetnames assign to
HI,
The branch seems to have issues with inner members of a relation. For
example, it complains that way 34672931 does not have a name but it is
the inner member of a named relation.
Thanks,
N.
___
mkgmap-dev mailing list
I have created a new branch for the automatic locator changes.
It can be downloaded from http://www.mkgmap.org.uk/snapshots/
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
20 matches
Mail list logo
