Hi Andrzej,
These object aren't tagged the same way, are they? It isn't a simple
case, where information is duplicated. There will be many ways to
interpret and use this informations. For example it could be
advantageous to move tags from area to point.
Right.
AFAICT, the source of the problem is the area-to-POI conversion, which
does not take into account that a more accurate POI (at the boundary
of the area) exists.
Area is an ordered list of poi. Some of them can have tags. You have
to be more precise to define a rule, when area-to-POI function should
be suppressed.
I think that the proper way to do that would be to define an action in
the style language that would somehow input the rules from the style
file. The action would be placed in the 'polygons' file, something like
this:
parking=* {
to_node(parking=* & amenity=parking,
{amenity=parking,mkgmap:area-to-poi=yes}
}
This new to_node action would take 2 parameters:
Parameter 1: A condition to match nodes in the polygon perimeter.
The tags from the polygon will be copied to the matching nodes.
Parameter 2: Tags to be added to a generated node, in case no nodes
matched parameter 1.
Let us consider an example where we have an area tagged as
parking=surface but without amenity=parking.
If any perimeter nodes of the area are tagged with parking=something and
amenity=parking, we would copy all tags from the area to these nodes.
If there were no such perimeter nodes, we would create a node in the
middle of the parking=* area, copying the original tags from the area
and adding amenity=parking,mkgmap:area-to-poi=yes.
This is just a quick sketch of the idea. We might want more flexibility
too, such as give a chance to filter out some tags when generating a
POI, or to compare the tags on the perimeter nodes to the tags on the
area.
Marko
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
