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
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> 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
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
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> 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
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
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@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> 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
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
-- 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.
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@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@.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
-- 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
Hi Gerd, removing fixme in code seems to be OK. You could even set option active by default. -- Best regards, Andrzej
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.
Hi Nick, yes, I also think that mkgmap should not modify the data by default. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von osm@ <pinns osm@pinns.co.uk> 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
On Tue, Mar 21, 2017 at 7:03 PM, Gerd Petermann < GPetermann_muenchen@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
participants (6)
-
Alexandre Loss -
Andrzej Popowski -
Dave Swarthout -
Gerd Petermann -
Gerd Petermann
-
osm＠pinns