Feedback on geography_type Field

[quicklywilliam]

I'm not convinced it makes sense to encode policy-specific concerns in the geography type.

First of, I'm not clear on the problems it is solving, so some context there would be helpful if anyone can provide! As is, I don't see the necessity.

Second, I'm worried that this new field confuses the modeling, leading to conflicts such as:

• What geometry_type should I use for a geography that has a slow ride policy and a no parking policy?
• A neighborhood wishes to prohibit scooters from being parked in their area. Should this be marked as a neighborhood type or a no_parking_zone?
• What type should I use for a policy that isn't one of the listed types?

[schnuerle]

For some background from the WG Meeting here: https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2020.10.08-(Joint-Working-Group-Provider-Services)#minutes

I think the problem it's solving is to be able to filter the Geography API results by type of geography, eg, to get a location of Stops, or polygons of equity zones, etc. And I think it helps:

1. understand what the geography was initially created for just by looking at the Geography API and not having to cross reference with Policy and Metrics or elsewhere
2. allow it to exist without connection to anything else
3. help the public understand it if all they can see is the geography API.

The WG call participants landed on adding it as an optional field with a list of suggested enumerated categories.

What geometry_type should I use for a geography that has a slow ride policy and a no parking policy?

I think you would create 2 geographies. This is how Louisville does it now. Some areas are slow ride zones, or no ride zones, or no parking zones. And since they are served up as different GIS layers now, there is duplication.

A neighborhood wishes to prohibit scooters from being parked in their area. Should this be marked as a neighborhood type or a no_parking_zone?

No parking zone. A neighborhood type would be more for analysis, maybe for Metrics, eg you can break a city into neighborhoods. If it happens to be both you would create 2 geometries.

What type should I use for a policy that isn't one of the listed types?

The spec says you can make up your own right now, and these are just suggestions. Also they don't have to be used at all.

[thekaveman]

@quicklywilliam:

I'm not convinced it makes sense to encode policy-specific concerns in the geography type.

I agree with this sentiment, and made some comments indicating as such on the PR that merged this field. Copied here for context:

...some of these Geography types feel like Policies more than descriptions of physical space. Do we want to mix those concerns?

Trying to think from an implementation perspective, how does a geography with type no_ride_zone or slow_ride_zone differ from the equivalent Policy document? If an agency publishes a Geography without a corresponding Policy, are companies expected to follow the type of the Geography as an implicit "rule"?

...[an] idea is to collapse those down to policy_zone or similar, to make it explicit that an associated Policy is needed. Then leave the details to the Policy/Rules. Would also make reusing the Geography across multiple (perhaps totally different) Policies more natural.

I do see the utility of classifying geographies using geopolitical terminology such as precinct, census_tract, municipal_boundary etc. and wanting to filter/aggregate information based on those values.

Here's the full list of geography_type again, with those that I am deeming "Policy-like" marked:

Value	Description
municipal_boundary	Edge of a city
*operating_area	Vehicle permitted operating area
*distribution_zone	An area of interest for distribution
*no_ride_zone	Areas where riding is not permitted
*no_parking_zone	Areas where parking is not permitted
*slow_ride_zone	Areas where top speed is reduced
county_boundary	Edge of a county
stop	See Stops
council_district	City council district
political_district	Politically defined voting area
neighborhood	Neighborhood area
market_area	Economic area
opportunity_zone	Defined Opportunity Zone
overlay_district	Agency overlay district
post_code	Zip or postal code
traffic_zone	Transportation planning area
property_line	One or more property lines
right_of_way	Public right of way area
census_block	Census block
census_block_group	Census block group
census_tract	Census tract

The suggestion I made on the PR was to collapse the Policy-like types into one policy_zone as a way to keep something of an indication that the Geography was defined strictly for the purposes of applying Policy.

[schnuerle]

@thekaveman Looking at your list of policy_zones, or geofences as Ben mentioned, do you think 'stop' should be included too?

[schnuerle]

I like the idea of a 'policy_zone' option, and thanks for categorizing the ones that could fit into that.

Since this whole list is just recommended text, and people can make up their own, I would argue that we keep the full list (maybe add policy_zone) so that there is some consistency around the ones cities will inevitably make up around policy areas.

These policy areas may not be defined in any other way in a city. For example, a no parking zone for scooters may not exist in any other form in the existing city geospatial areas.

And if we want Geography to be public and allow others to ingest this feed, I think adding some kind of context here for these geographies would be useful, even if it's just one optional field. I know Policy could also be public, but it would require some matching of the 2 feeds to make sense of the area. And I think Geography could be optionally public, while Policy could separately be optional public, so Policy may not be available to make sense of a Geography.

This does create some duplicity across these 2 APIs, with having to setup similar but more details in Policy as well, but I argue it's worth it in this case.

Note we do have this language now above the Type table to make it clear these are optional fields and not meant for policy:

geography_type does not imply policy or required actions by providers, but instead is for organizational and discovery purposes within the standalone Geography API. Geographies need to be referenced from other areas of MDS to be meaningfully applied.

[jrheard]

This does create some duplicity across these 2 APIs, with having to setup similar but more details in Policy as well, but I argue it's worth it in this case.

One thing that concerns me about this kind of denormalization is that it allows for new categories of mistake to creep into a system. If the Geography API says that a particular Geography is a no_parking_zone, but the Policy API contains a Policy that says that that same Geography has (say) a minimum deployment of 20 vehicles and a max of 200 vehicles, how should a consumer of these two APIs interpret the situation? If the two APIs conflict, which one of them is correct? Do we need to write that down somewhere?

If we're opening ourselves up to a situation where there's potential ambiguity that needs to be resolved by special precedence rules that need to be clearly recorded somewhere, we're spending a nonzero amount of our complexity budget. IMO that's OK if we're trying to implement something super important that our users are asking for, but I haven't really gotten that impression here.

Kegan's idea sounds pretty good to me! :)

[schnuerle]

I think it's clear now that this is not to be used for policy. But maybe some more language reinforcing the fact that Policy takes precedence could help.

1. Maybe another solution here is to not use enum style values, and instead use words, eg 'No parking zone' instead of 'no_parking_zone'. This maybe causes some potential issues with typos, but it makes clear these are not enumerated type values.

2. And/or instead of calling the table column "Value" it could change to "Recommended Text"

3. And/or the geography_type name could change to something like type_description or short_description (which should be separate from description since that has its own uses).

[marie-x]

I'd say we should recommend staying clear of policy-implying types, but not make it super free-form. See the Metrics use-cases.

[schnuerle]

@Karcass for the Metrics use cases, do you mean when Metrics refers to Geography IDs? If so and a geography is only used in Metrics and not in Policy, and Metrics is private, how is the public supposed to reliably use the geography (besides divining a use from the name and description)?

[bhandzo]

I feel strongly that we should not put anything that looks like policy information in the types in geography. So I would advocate the following:

geofence for geospatial regions that only exist for some sort of 'restriction' to be attached via policy (no parking, no riding, speed limit, etc.). This would replace those types.

We could also include a type of policy for operating and distribution zones.

[marie-x]

+1

[schnuerle]

@bhandzo what are you thinking of for including operating and distribution zones in policy, you mean more clearly defined than the way it is now? Operating area is in there, and distribution zone is covered a la this example.

[schnuerle]

Per discussions here and on the last call, I rolled policy types into new policy_zone field (vs geofence since I think this is more explicit that it relates to the Policy endpoint) in this branch soon to be a PR.