[mkgmap-dev] fixme rules

Tue Mar 21 11:03:14 GMT 2017

In dispite we don't have this kind of problem in our Brazilian project (we
don't use OSM as source for maps), I agree with you that the first option
is better.

Alexandre

2017-03-21 7:04 GMT-03:00 Gerd Petermann <gpetermann_muenchen at hotmail.com>:

> 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 at .org
>
> > > im Auftrag von Andrzej Popowski <
>
> > popej at .onet
>
> > >
> > Gesendet: Donnerstag, 9. März 2017 14:44:28
> > An:
>
> > mkgmap-dev at .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 at .org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
>
> > mkgmap-dev at .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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170321/418fa5e2/attachment-0001.html>