Cannot add a service=parking_aisle to bus route relation about osm-relatify HOT 9 CLOSED

@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:

from osm-relatify.

This type issue was already resolved yesterday: #2

from osm-relatify.

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.

from osm-relatify.

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

from osm-relatify.

@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?

from osm-relatify.

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:

from osm-relatify.

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.

from osm-relatify.

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.

from osm-relatify.

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.

from osm-relatify.