[mkgmap-dev] fixme rulesFrom Gerd Petermann gpetermann_muenchen at hotmail.com on Tue Mar 21 10:04:21 GMT 2017
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.
- Previous message: [mkgmap-dev] fixme rules
- Next message: [mkgmap-dev] fixme rules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list