<div dir="ltr">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.<div><br></div><div>Alexandre</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-21 7:04 GMT-03:00 Gerd Petermann <span dir="ltr"><<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank">gpetermann_muenchen@hotmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
any feedback on this?<br>
I see several ways to improve fixme handling.<br>
1) add a new option --ignore-fixme-values which is used when<br>
reading osm data and means: ignore all tags when the value matches the fixme<br>
pattern '(?i)fix[ _]?+me'<br>
Disadvantage:<br>
- Would add a regular expression check for each tag<br>
- user has no control if he wants only certain tags to be cleaned up<br>
- requires new option<br>
Advantage: Removes the values before they can cause trouble in routines<br>
which try to find a name.<br>
(e.g. if name-list says name:de,name_loc,name)<br>
<br>
2) In the style, as an include like Andrzejs patch sugested.<br>
Disadvantages:<br>
- Internal routines might evaluate the unwanted tags before style<br>
processing.<br>
- For ways the rules may be tested twice (when rules for lines and shapes<br>
are concatenated)<br>
(not sure if this matters)<br>
Advantage:<br>
- no new option needed<br>
<br>
I think 1) is better.<br>
<br>
Gerd<br>
<br>
<br>
<br>
Gerd Petermann wrote<br>
> Hi Andrzej,<br>
><br>
> yes, I agree that we have some rules which might be improved. I just try<br>
> to make up my mind what is best.<br>
><br>
> The POI for MP-relations are generated with special code which also<br>
> searches for nodes with role=label or role=admin_centre.<br>
> For ways not generated from MP-relations the POIGenerator checks only if<br>
> the way is closed or not, all closed ways are treated as area.<br>
> (all this happens before processing the rules in points, lines, or<br>
> polygons)<br>
><br>
> I've verified that the code in MultipolygonRelatiion creates multiple<br>
> ways, all tagged with mkgmap:mp_created=true<br>
> - One for each outer ring with tag mkgmap:stylefilter=polyline, these are<br>
> only processed by the lines rules<br>
> - One or more for the areas (after splitting to cut out holes) with tag<br>
> mkgmap:stylefilter=polygon, these are only processed by the polygon rules<br>
><br>
> I agree that the fixme rules should be placed in an include that is placed<br>
> at the beginning of points, lines and polygons,<br>
> but what about relations?<br>
><br>
> Another problem: Assume you have a way with name=XYZ and name:de=Fixme and<br>
> --name-tag-list=name:de,name<br>
> I guess one would prefer to see name=XYZ instead of Fixme (or null if<br>
> fixme rules were applied) in that case.<br>
><br>
> I start to believe that the fixme handling should (again) be done in Java<br>
> code.<br>
><br>
> Gerd<br>
> ______________________________<wbr>__________<br>
> Von: mkgmap-dev <<br>
<br>
> mkgmap-dev-bounces@.org<br>
<br>
> > im Auftrag von Andrzej Popowski <<br>
<br>
> popej@.onet<br>
<br>
> ><br>
> Gesendet: Donnerstag, 9. März 2017 14:44:28<br>
> An:<br>
<br>
> mkgmap-dev@.org<br>
<br>
> Betreff: Re: [mkgmap-dev] fixme rules<br>
><br>
> Hi Gerd,<br>
><br>
> I think you are considering other problem then I. I'm not talking about<br>
> inner/outer line, but about proper recognizing if OSM object is an area.<br>
><br>
> Actually a rule, which adds area=yes is already present in lines. And<br>
> some tests for mkgmap:mp_created are present in polygons, see<br>
> highway=pedestrian.<br>
><br>
> This rule isn't useful for pois, but I wonder how mkgmap creates poi<br>
> from areas. Does it test for multipolygon or area=yes?<br>
><br>
> --<br>
> Best regards,<br>
> Andrzej<br>
> ______________________________<wbr>_________________<br>
> mkgmap-dev mailing list<br>
<br>
> mkgmap-dev@.org<br>
<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
> ______________________________<wbr>_________________<br>
> mkgmap-dev mailing list<br>
<br>
> mkgmap-dev@.org<br>
<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gis.19327.n8.nabble.com/fixme-rules-tp5892639p5893690.html" rel="noreferrer" target="_blank">http://gis.19327.n8.nabble.<wbr>com/fixme-rules-<wbr>tp5892639p5893690.html</a><br>
Sent from the Mkgmap Development mailing list archive at Nabble.com.<br>
______________________________<wbr>_________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a></blockquote></div><br></div>