El 09/12/14 a las 16:38, Gerd Petermann escribió:
Hi all,
attached is v2.
It turned out to be quite complicated to interpret the data
provided with this tag, and I found only few places were this
helps to provide better data. On the other hand, I see no negative
effects besides the additional
Hi Carlos,
thanks for the feedback.
I must confess that I was a bit surprised about the improvement.
In other words, I thought that I might have found an error
in the existing code, so I started to look closer at the HousenumberGenerator,
also because of the addr:place problem.
@WanMil: Do you
El 11/12/14 a las 11:20, GerdP escribió:
Hi Steve,
If I got it right, we need these changes:
1) an option to pass the polgon(s) to mkgmap.
I don't know which format is good for this. In splitter we use the OSM
(xml, o5m, pbf) format to pass named polygons (with --polygon-desc-file)
or the
Hi Carlos,
yes, you are right, and splitter is using it.
I thought the missing name was the reason for the introduction of the
polygon-desc-file parameter in splitter, but in fact it was the possibility to
define multiple areas with different names, and I think that is not possible
with the
Hi Gerd,
what about a simple solution, that could be used for tests?
I mean to add a support for bounding poly to mkgmap as an input option,
for example:
--bounding-poly=12345678.poly
With this option mkgmap could define tile area as a common area of a
polygon and bounding box inside osm
Hi Andrzej,
as I wrote before I see no need to change splitter.
Even if we would be able to store and calculate the exact shape of
each element within splitter, we would have to write
data outside of the polygon so that ways etc. are complete.
So, the only improvement would be a reduction of
Hi Gerd,
there are some tasks, which splitter could automatize. But I'm more
interested in getting a working map than optimizing workflow. That's why
I ask to start with mkgmap ;)
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
