Hi all,

any feedback on this?
I see several ways to improve fixme handling.
1) add a new option --ignore-fixme-values which is used when
reading osm data and means: ignore all tags when the value matches the fixme
pattern '(?i)fix[ _]?+me'
Disadvantage:
- Would add a regular expression check for each tag
- user has no control if he wants only certain tags to be cleaned up
- requires new option
Advantage: Removes the values before they can cause trouble in routines
which try to find a name.
(e.g. if name-list says name:de,name_loc,name)

2) In the style, as an include like Andrzejs patch sugested.
Disadvantages:
- Internal routines might evaluate the unwanted tags before style
processing.
- For ways the rules may be tested twice (when rules for lines and shapes
are concatenated)
(not sure if this matters)
Advantage:
- no new option needed

I think 1) is better.

Gerd



Gerd Petermann wrote
> Hi Andrzej,
>
> yes, I agree that we have some rules which might be improved. I just try
> to make up my mind what is best.
>
> The POI for MP-relations are generated with special code which also
> searches for nodes with role=label or role=admin_centre.
> For ways not generated from MP-relations the POIGenerator checks only if
> the way is closed or not, all closed ways are treated as area.
> (all this happens before processing the rules in points, lines, or
> polygons)
>
> I've verified that the code in MultipolygonRelatiion creates multiple
> ways, all tagged with mkgmap:mp_created=true
> - One for each outer ring with tag mkgmap:stylefilter=polyline, these are
> only processed by the lines rules
> - One or more for the areas (after splitting to cut out holes) with tag
> mkgmap:stylefilter=polygon, these are only processed by the polygon rules
>
> I agree that the fixme rules should be placed in an include that is placed
> at the beginning of points, lines and polygons,
> but what about relations?
>
> Another problem: Assume you have a way with name=XYZ and name:de=Fixme and
> --name-tag-list=name:de,name
> I guess one would prefer to see name=XYZ instead of Fixme (or null if
> fixme rules were applied) in that case.
>
> I start to believe that the fixme handling should (again) be done in Java
> code.
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <

> mkgmap-dev-bounces@.org

> > im Auftrag von Andrzej Popowski <

> popej@.onet

> >
> Gesendet: Donnerstag, 9. März 2017 14:44:28
> An:

> mkgmap-dev@.org

> Betreff: Re: [mkgmap-dev] fixme rules
>
> Hi Gerd,
>
> I think you are considering other problem then I. I'm not talking about
> inner/outer line, but about proper recognizing if OSM object is an area.
>
> Actually a rule, which adds area=yes is already present in lines. And
> some tests for mkgmap:mp_created are present in polygons, see
> highway=pedestrian.
>
> This rule isn't useful for pois, but I wonder how mkgmap creates poi
> from areas. Does it test for multipolygon or area=yes?
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: http://gis.19327.n8.nabble.com/fixme-rules-tp5892639p5893690.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev