Modify

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9311 closed enhancement (fixed)

ParkingNodeInParkingWay validator

Reported by: kalle Owned by: team
Priority: normal Milestone: 14.01
Component: Core validator Version:
Keywords: parking Cc:

Description

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.

Attachments (2)

ParkingNodeInParkingWay.diff (3.7 KB) - added by kalle 6 years ago.
ParkingNodeInParkingWay.2.diff (11.6 KB) - added by kalle 6 years ago.
Version that does not warn if node has (capacity:disabled !=null && !"no") and way does not.

Download all attachments as: .zip

Change History (19)

Changed 6 years ago by kalle

comment:1 Changed 6 years ago by kalle

Summary: ParkingNodeInParkingWayParkingNodeInParkingWay validator

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by mkoniecz

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

comment:4 in reply to:  3 Changed 6 years ago by 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.

Last edited 6 years ago by kalle (previous) (diff)

Changed 6 years ago by kalle

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

comment:5 Changed 6 years ago by 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 ?

comment:6 in reply to:  5 ; Changed 6 years ago by 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.

Last edited 6 years ago by kalle (previous) (diff)

comment:7 in reply to:  6 Changed 6 years ago by 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.

comment:8 Changed 6 years ago by 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");
}

comment:9 Changed 6 years ago by mkoniecz

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

comment:10 in reply to:  9 Changed 6 years ago by 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 …

comment:11 Changed 6 years ago by mkoniecz

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

Last edited 6 years ago by mkoniecz (previous) (diff)

comment:12 Changed 6 years ago by simon04

Resolution: fixed
Status: newclosed

In 6614/josm:

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

comment:13 Changed 6 years ago by simon04

Milestone: 14.01

comment:14 Changed 6 years ago by 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.

comment:15 Changed 6 years ago by simon04

Resolution: fixed
Status: closedreopened

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

comment:16 Changed 6 years ago by simon04

Resolution: fixed
Status: reopenedclosed

In 6628/josm:

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

comment:17 Changed 6 years ago by 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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.