Cannot add a service=parking_aisle to bus route relation

[claysmalley]

Example route (Golden Gate Transit bus 101, California, US): relation 9525119

Problematic parking aisle: way 770028951

This parking aisle is physically part of the bus route, and as such, is mapped as part of the relation. However, the parking aisle is unrecognized by Relatify, so it won't show up and I can't complete a continuous route.

[mutipg]

I think it could be a solution to add for that type of roads psv=yes/designated or bus=yes/designated tag.

I already did it for that way. Lets check in again in few minutes :)

edit:
After data update you can select that way:

[mutipg]

This type issue was already resolved yesterday: #2

[claysmalley]

At time of writing, there are 3807 ways belonging to bus route relations in the United States that are tagged with service=parking_aisle but empty psv and bus. Are you suggesting these all need to be retagged before Relatify will recognize them? It seems like a huge burden on the community to require psv=yes|designated just to make this work in a particular OSM editor, where there is no access restriction otherwise and no relevant signage.

[Zaczero]

@claysmalley

Here are the complete statistics:

• driveway: 3176 ways
• parking_aisle: 3807 ways
• alley: 94 ways
• emergency_access: 7 ways

If we include parking_aisle by default, the same argument could be made for including driveways by default. Most examples of the use of parking_aisle are simply incorrect tagging, as the wiki states: "a subordinated way in a parking lot between rows of parking spaces that vehicles use to drive into and out of the spaces". This presents a good opportunity to reconsider the status of the road, potentially upgrading it to a service road. Alternatively, you can simply override access with psv/bus for those 1% of valid cases.

I aim to strike a balance between ease of use and compatibility. Including all driveways and parking aisles by default would be overwhelming and make the interface harder to use, as there would be more roads to toggle. Therefore, I am willing to sacrifice some compatibility in order to make it easy to spot areas needing improvement and keep the app simple and user-friendly.

I believe that the need to occasionally correct road types has a positive side effect. It doesn't require much time and makes the editing task less repetitive. I see the correction of road types as a crucial part of the overall bus edit process.

---

In this specific example, the marked part of the road should be upgraded to service. This section of the road is not solely used for getting in and out of parking spaces. It appears to be a primary route for traversing through the parking area, between the entrances. And it is also used by buses. Parking aisle seems like a mistake here. I would also consider upgrading the other side as well:

[Zaczero]

Using an Overpass query to search for both driveway and parking_aisle without the psv/bus tags, which are parts of the bus routes, sounds like a great idea for a challenge on https://maproulette.org.

[claysmalley]

Sounds like this is a tagging issue then. I'll bring it up with the US community. Thanks!

[osm-ToniE]

@claysmalley

At time of writing, there are 3807 ways belonging to bus route relations in the United States that are tagged with service=parking_aisle but empty psv and bus.

PTNA does not allow this service=* tags at all for vehicles if the analysis option --check-servcie-type is set - which is always the case.

Would it make sense to check for psv=yes|designated or bus=yes|designated and allowing driveway and parking_aisle?

[claysmalley]

I think it's clear that this is a tagging issue. Perhaps PTNA should check for psv and bus like Relatify does, but allowing all driveways and parking aisles would seem contrary to tagging conventions.

[osm-ToniE]

Agreed, I will introduce a new analysis option --check-service-type-relaxed so that PTNA will not complain for driveway and parking_aisle if psv/bus=yes/designated is set.