Mechanical edit Proposal to clean up obvious typos in area=* tag

General talk Tagging general discussion
,
1

I just realized that there are a lot of litte mistakes in the values of area=* tags. There are objects mapped with "area"="yesaccess=private" (12x), "area"="yesarea=yes" (10x) or similar obvious typos. So someone was trying to set 2 tags but accidently set only one of them with a not sensfull value. You can find about 70 of these by searching for “yes” in taginfo.

I would like to clean that up. I would change "area"="yesaccess=private" to "area"="yes" + "access"="private". I would do the same to all of the other obvious typos where area=* got mearched with an additional tag.

Does anyone see a problem with this?

6 Likes
2

what about cases where access tag is set already to values other than private? I would skip them

2 Likes
3

How do you know that access=private is correct?

4

Thats a good point. I didn’t find any case where this is relevant but I did not da a detailed analysis of that. I would skip them and maybe try to sort that out by contacting the mapper who added the tag, adding a fixme=* or opening a note. I don’t want to overwrite existing tags with the content of area=*.

I don’t. My plan is to assume that access=private was intended to be added. Do you think this assumption is reasonable?

9 Likes
5

As in total 5 people gave a thums up on my two posts in this thread I documented the proposed edit in the wiki. I added the plan to repeat this edit in case I notice that the same mistakes reappear.

I will wait a few more days untill I start editing to give anyone the chance to ask questions or object to the proposal.

Is any information missing in my wiki entry?

6

I would not assume this in an automated way. Since it wasn’t existing in the data in a usable form and nobody seems to miss that access, it might be ok without access=private as well. Same might go for area=yes. I would only add it automatically, if other tags of that object support area=yes is proper. Having 70 occurrences only it might be better, to do this fix manually and review the fix against aerial image.

2 Likes
7

If I understand you right you suggest to manually check for plausibility before editing. I thought about doing this for some of the questionable values of area=*, where I see no chance for an automated edit (area=amenity (8x), area=new (5x), area=highway- proposed (4x), …).

5 people gave a thumb up on my post saying that I want to assume that the two mearged tags were both intended to be set. Now one person opposed to that and one person gave a thumb up to this. Now I am not sure.

It would be great if checking all the ~150 elements (with ~70 different values) could be skipped but I realy don’t want to break data. The objects I checked earlyer were plausible, but I only checked a very small amount.

How do other see this? Is the assumption that tags like "area"="yesaccess=private" are typos of "area"="yes" + "access"="private" reasonable? Schould every object be checked for plausabilaty? Should every object be checked for correctnes?

1 Like
8

Not exactly. It might have been a typo. If that typo happened yesterday, it I’m good with simply fixing it. Though if some time past, might be someone else added another object with proper data, it might be outdated meanwhile,…

Would you add such kind of information from a 2 years old note without further evidence? I would at least check the aerial, whether it still makes sense :wink:

1 Like
9

If I add Information from a note I of course check for plausabilaty based on the aerial image. But I don’t realy have a choice since it is a manuall edit anyways. And a note normally does not contain information already formulated in tags.
Here someone tryed to add 2 tags but messed it up and mearged them into a meaningless one.

I don’t think that there is a high change that the object is mapped once correctly and once with the messed up mearged tags. That is something most mappers would realise before adding the object a second time.

10

My point is simply that the quality of information is similar.

That would be something you as the one doing the mechanical edit need to validate, that it’s the case. Not just thinking, it might be the case :wink:

11

I think that this is a very solid assumption and that your proposed edit is almost certainly a net benefit.

In my opinion, it is not reasonable to demand that someone fixing obvious syntactic issues (such as these typos) must also verify semantic correctness of every element they touch.

1 Like
12

When looking at the list at taginfo, I think most of those objects should not be tagged with “area=yes”.

  • area=yesaddr:housenumber=… → Probably buildings. No area=yes necessary.
  • area=yesamenity=parking → amenity=parking. No area=yes necessary.
  • area=yesfarmland=pasture → Probably landuse=farmland. No area=yes necessary.
    …

Instead of converting “area=yesamenity=parking” to “area=yes” + “amenity=parking” it should be converted to “area=yes” “amenity=parking”

Manual review for every object should be done.

Edit:
I have manually fixed all 70 objects that were tagged with “area=yes…” (Everything that is listed when filtering for “yes” @ taginfo ) :slightly_smiling_face:

Not a single one of these objects should have been tagged with “area=yes”.

8 Likes
13

Thank you for doing that work.

That is very interesting and something that I didn’t expect. I am glad that these errors are now removed from the database.

A few days ago I posted this:

I got 7 upvotes on this post and no downvote. It is astonoshing haw many people agreed with me even though my proposal was bad.

14

My explanation would be:
If you draw an area with ID Editor and then unselect the new polygon without giving it some properties, ID automatically adds “area=yes” to the polygon:
grafik
I assume some users then copy-pasted the tags of some other object to the new one without noticing the “area=yes”. That could lead to something like this:
grafik

1 Like