Re: [mkgmap-dev] fixme rules
On Tue, Mar 21, 2017 at 7:03 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > yes, I also think that mkgmap should not modify the data by default. +1 -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
Hi Nick, yes, I also think that mkgmap should not modify the data by default. Gerd Von: mkgmap-dev im Auftrag von osm@ Gesendet: Dienstag, 21. März 2017 12:50:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] fixme rules Hi Gerd Personally I would not recommend setting the option active by default as some osm plotters may want to tag fixmes as a quick and visual way to highlight and address possible fixmes. I create maps showing fixme pois with labels containing the actual fixme statement. r Nick On 21/03/2017 11:39, Andrzej Popowski wrote: > Hi Gerd, > > removing fixme in code seems to be OK. You could even set option > active by default. > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
Hi Gerd Personally I would not recommend setting the option active by default as some osm plotters may want to tag fixmes as a quick and visual way to highlight and address possible fixmes. I create maps showing fixme pois with labels containing the actual fixme statement. r Nick On 21/03/2017 11:39, Andrzej Popowski wrote: Hi Gerd, removing fixme in code seems to be OK. You could even set option active by default. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
Hi Gerd, removing fixme in code seems to be OK. You could even set option active by default. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
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 : > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
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
Re: [mkgmap-dev] fixme rules
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 im Auftrag von Andrzej Popowski Gesendet: Donnerstag, 9. März 2017 14:44:28 An: mkgmap-dev@lists.mkgmap.org.uk 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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
Hi Andrzej, if my assumption is right that mkgmp produces two different ways one can probably simple delete the one that appears in the lines rules if no outlines are wanted. I'll check this again. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Mittwoch, 8. März 2017 20:06:52 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] fixme rules Hi Gerd, I use rule for multipolygon, because it is convenient. Style already include many tests for tag "area". In most cases there should be added test for multipolygon, because multipolygon by default is area, so could miss the tag. Single rule at the beginning corrects it all. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
Hi Gerd, I use rule for multipolygon, because it is convenient. Style already include many tests for tag "area". In most cases there should be added test for multipolygon, because multipolygon by default is area, so could miss the tag. Single rule at the beginning corrects it all. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
Hi Andrzej, one remark: The tag mkgmap:mp_created is set for all ways created from mp-relations. An additional tag mkgmap:stylefilter is set This tag is also used to decide which rules are used for the way: mkgmap:stylefilter=polyline means: use only the lines rules mkgmap:stylefilter=polygon means: use only the polygons rules The comment in MultipolygonRelation.java says: // Go through all original outer ways, create a copy, tag them // with the mp tags and mark them only to be used for polyline processing // This enables the style file to decide if the polygon information or // the simple line information should be used. I did not try, but If I got that right you should see two different ways for each outer way of a mp-relation. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Dienstag, 7. März 2017 18:21:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] fixme rules Hi, there are some rules in include/name, designed to remove "fixme" value from tags. Unfortunately they are executed too late for many cases, for example for highway "name" and "ref". I propose to add a file include/fixme to default style and include it at the beginning of points, lines and polygon files. This file could contain fixme rules and other rules, that are useful for all objects. I have found these functions useful: - fixme rules - setting mkgmap:country tag, - correction for multipolygon without area=yes - forcing finalize stage for address I have attached proposed patch to this mail. It duplicate some rules from other includes, which could be removed there, but I haven't done it yet. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] fixme rules
Hi,
there are some rules in include/name, designed to remove "fixme" value
from tags. Unfortunately they are executed too late for many cases, for
example for highway "name" and "ref".
I propose to add a file include/fixme to default style and include it at
the beginning of points, lines and polygon files. This file could
contain fixme rules and other rules, that are useful for all objects. I
have found these functions useful:
- fixme rules
- setting mkgmap:country tag,
- correction for multipolygon without area=yes
- forcing finalize stage for address
I have attached proposed patch to this mail. It duplicate some rules
from other includes, which could be removed there, but I haven't done it
yet.
--
Best regards,
Andrzej
Index: resources/styles/default/inc/fixme
===
--- resources/styles/default/inc/fixme (nonexistent)
+++ resources/styles/default/inc/fixme (working copy)
@@ -0,0 +1,13 @@
+# set the country code for country dependent rules
+mkgmap:country!=* & mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
+mkgmap:country!=* & addr:country=* { set
mkgmap:country='${addr:country|country-ISO:}' }
+mkgmap:country!=* & is_in:country=* { set
mkgmap:country='${is_in:country|country-ISO:}' }
+
+# delete FIXME values (they should be better used in maintenance maps)
+ref ~ '(?i)fix[ _]?+me'{ delete ref; }
+name ~ '(?i)fix[ _]?+me' { delete name; }
+
+# correct multipolygons without area=yes
+mkgmap:mp_created=true { add area=yes }
+
+addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 3834)
+++ resources/styles/default/lines (working copy)
@@ -8,7 +8,7 @@
# and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
# for more information.
-addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
+include 'inc/fixme';
aeroway=runway & highway!=* & is_closed()=false {name '${ref}'} [0x27
resolution 20]
(aeroway=taxiway | aeroway=taxilane) & highway!=* & is_closed()=false {name
'${ref}'} [0x27 resolution 24]
Index: resources/styles/default/points
===
--- resources/styles/default/points (revision 3834)
+++ resources/styles/default/points (working copy)
@@ -8,7 +8,8 @@
# and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
# for more information.
-addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
+include 'inc/fixme';
+
barrier=* & bicycle=*{ set mkgmap:bicycle='${bicycle|subst:private=>no}' }
barrier=* & foot=* { set mkgmap:foot='${foot|subst:private=>no}' }
barrier=* & hgv=*{ set mkgmap:truck='${hgv|subst:private=>no}' }
Index: resources/styles/default/polygons
===
--- resources/styles/default/polygons (revision 3834)
+++ resources/styles/default/polygons (working copy)
@@ -8,7 +8,7 @@
# and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
# for more information.
-addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
+include 'inc/fixme';
leisure=* & sport=* & name=* { set name='${name} (${sport})' }
leisure=* & sport=* & name!=* { add name='${sport}' }
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
