Quantcast

fixme rules

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

fixme rules

popej
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

fixme.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

Gerd Petermann
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 <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Dienstag, 7. März 2017 18:21:21
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

popej
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

Gerd Petermann
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 <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Mittwoch, 8. März 2017 20:06:52
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

popej
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

Gerd Petermann
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 <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Donnerstag, 9. März 2017 14:44:28
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

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 <[hidden email]> im Auftrag von Andrzej Popowski <[hidden email]>
Gesendet: Donnerstag, 9. März 2017 14:44:28
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

Alexandre Loss
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 <[hidden email]>:
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

popej
In reply to this post by Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

nwillink
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

Gerd Petermann
Hi Nick,

yes, I also think that mkgmap should not modify the data by default.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von osm@ <pinns [hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fixme rules

Dave Swarthout

On Tue, Mar 21, 2017 at 7:03 PM, Gerd Petermann <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Loading...