ParkingNodeInParkingWay validator

[kalle]

This validator search for nodes tagged with amenity=parking that are located (i.e. not a member of) inside of enclosed ways (polygons) also tagged with amenity=parking.

[kalle]

It should probably not be reported as an error if the node is marked as handicap parking within a way that is not marked as such.

[mkoniecz]

It may be more general - node inside area, with the same set of tags.

[kalle]

Replying to Bulwersator:

It may be more general - node inside area, with the same set of tags.

Would only be applicable if it searched for some one tag, say amenity=*. It's quite common that the node has a complete different set of other tags associated with it compared to the way, name, etc.

You can check out the output from a script I wrote in order to find the parking problems in Sweden, it shows in detail why your suggestion would not apply.
<​http://osm.kodapan.se/parkering/parking.osm.xml>

However, a validator as the one you suggest sounds as a good idea too, I just think it's a validator different from the one I've attached here.

[kalle]

Version that does not warn if node has (capacity:disabled !=null && !"no") and way does not.

[Don-vip]

Agreed it needs to be more general we won't make a test per feature, aka parking in parking, cafe in cafe, and so on. Don't we already have a ticket for this ?

[kalle]

Replying to Don-vip:

Agreed it needs to be more general we won't make a test per feature, aka parking in parking, cafe in cafe, and so on. Don't we already have a ticket for this ?

But you do also understand that "parking in parking" might in at least a couple instances be correct? A generic validation as suggested by you and Bulwesator will thus produce false positive validation errors. E.g. a driveway to next parking level is a node that could exist in a way, so is disabled spaces in a lot otherwise filled with non disabled spaces, and so on.

I prefer no warnings to false positives.

I'm sure that the same applies to many other tag schemes, parking in parking is however an extremely common occurring error everywhere I've been looking.

And to be quite honest, I'm not sure why you wouldn't want as detailed validation as possible available in JOSM. People who don't want validation can turn that feature off, and if it's spending time waiting for the validation process that feels wrong then not validating in detail is fixing the symptom rather than the real problem, where the solution to the real problem would be making validation a speedier process. Perhaps using groups of "quick validation" and "detailed validation", execute them multi threaded, optimise them or what not. The whole idea with validation is to avoid committing bad data and fixing already existing bad data.

Personally I see no problem /what so ever/ with thousands of validation strategies implemented in JOSM.

[skyper]

Replying to kalle:

Replying to Don-vip:

Agreed it needs to be more general we won't make a test per feature, aka parking in parking, cafe in cafe, and so on. Don't we already have a ticket for this ?

Did only find #8956 which does not fit but reminded me that we have not only closed ways but also multipolygons.

Personally I see no problem /what so ever/ with thousands of validation strategies implemented in JOSM.

We can still handle some special cases but a general test makes sense.

[simon04]

I'm working on an extension of MapCSS which supports a "contains" condition. When it's finished, the test would look like (using the Unicode symbol with the adequate name "CONTAINS AS MEMBER"):

*[amenity=parking] ∋ node[amenity=parking] {
  throwWarning: tr("node {0} found inside of {1}", "amenity=parking", "amenity=parking");
}

[mkoniecz]

Sorry, but using "∋" sign is a really bad idea. ~ in C++ destructors is already irritating, and this is evil.

[simon04]

Replying to Bulwersator:

Sorry, but using "∋" sign is a really bad idea. ~ in C++ destructors is already irritating, and this is evil.

That comment is not that helpful. An alternative suggestion would have been. (Btw: ~ is a plain ASCII symbol which has been defined in 1963 or so …)

I'm currently more concerned on an efficient implementation …

[mkoniecz]

"contains" or "includes"? ~ is problematic as it requires more than one keypress on normal keyboard.

[simon04]

In 6614/josm:

fix #9311 - Add amenity=parking inside amenity=parking validation (based on MapCSS)

[kalle]

In my opinion the commit is not so great as it's lacking the feature of the second patch I added here: that it does not warn if node has (capacity:disabled !=null && !"no") and way does not, as that would be a rather valid node.

I fear that in the future someone will remove this validation because it does not seem to make sense, generating warnings on all handicap parking spots.

[simon04]

Sorry, I overlooked this additional check, but that should be easy to add.

[simon04]

In 6628/josm:

fix #9311 - add capacity:disabled aspect to amenity=parking inside amenity=parking validation

[simon04]

In 6719/josm:

fix #9522 - New test for nodes inside polygons with the same values
see #9311 - Repair parking inside parking if capacity:disabled is not set