Tool for building simple, static 'policy' endpoints (Request For Interest)

[jfh01]

Now that the policy API is live, I'm curious about interest in having a tool to build simple, static expressions of a policy endpoint. For example, something that could convert a shapefile from GIS into a policy that express prohibited riding and/or parking zones. Or, perhaps a visual tool for building out zones. The idea is to make it easier for cities to implement simple use cases of policy without needed to stand up a full, dynamic endpoint.

Is this something that folks think would be useful? Any interest in building?

(Credit to @contra, who suggested this in conversation a few months ago.)

[marie-x]

I would say "policy documents" rather than "policy endpoints" if you want just static files as output (one for a policy, one for a geography).

If you start with a GeoJSON MultiPolygon as the shapefile, it could be used as-is.

A few lines of (e.g.) Python could prompt for inputs and generate a Policy object.

Happy to support an outside effort, or I can get someone at E&A to do it.

[ascherkus]

We were thinking about something similar -- happy to prototype something. Let me know if there are some cities out there that could use this that we can test with!

[thekaveman]

@ascherkus we'd be happy to test out a prototype of something like a Shapefile -> Policy file(s) converter, more so if it could work with ESRI endpoints a la those on https://gis-smgov.opendata.arcgis.com/datasets/mobility-prohibited-riding-areas.

[ascherkus]

Cool. I'll hack something up!

On Wed, Jan 15, 2020, 6:16 PM Kegan Maher notifications@github.com wrote:

@ascherkus https://github.com/ascherkus we'd be happy to test out a prototype of something like a Shapefile -> Policy file(s) converter, more so if it could work with ESRI endpoints a la those on https://gis-smgov.opendata.arcgis.com/datasets/mobility-prohibited-riding-areas .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openmobilityfoundation/mobility-data-specification/issues/423?email_source=notifications&email_token=AAFE7Z3KZ22EDCCLFVNAUPDQ56KNVA5CNFSM4KERFUDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJCE5BI#issuecomment-574901893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFE7ZZFGWTNS3WU2RKWKELQ56KNVANCNFSM4KERFUDA .

[jfh01]

Just sent a note to the other OMF public sector members to find other cities who might be interested in testing/using this.

[schnuerle]

Louisville is interested in helping scope this for when the source is a GIS file (like shapefile or geojson) that has some appropriate tagging/categories/names for zones like no parking, preferred parking, no riding, 5 mph, 15 mph, x mph, operating area, distribution zones, etc.

We currently deliver these files to providers via files linked to from our open data page at these locations:

• Speed regulation, no parking, no ride
• Service Area
• Distribution Zones

[jfh01]

Josh Johnson from Minneapolis also expressed interest in trying something like this out.

[ascherkus]

Thanks for the pointers! I have a basic proof of concept working - but I agree with @schnuerle that it seems like there'd need to be some way of having common tags/metadata to make this automated and less error-prone.

For example, the Louisville regulated speed shapefiles have a MaxSpeed attribute present, that could be interpreted into the corresponding speed rule type... but even then we'd rely on the default behaviour for the rest of the fields (e.g., rule_units, propulsion_types, vehicle_types). That might lead us down the route of creating an official Shapefile Metadata -> MDS Policy mapping... not sure if that's desirable or not.

If the source is a GeoJSON - I believe the natural spot for additional metadata would be the properties object for each Feature ... but then again we'd end up with something like re-defining the existing Policy API inside GeoJSON features (basically inverting the relationship between geometries and policies).

Aside from that I'm sure there's a less-automated / more-WYSIWYG approach where the basic shape is ingested and people can tick checkboxes / punch in numbers and then publish and save the result.

Would love to talk with folks to understand a bit more about the desired workflow / process!

[yocontra]

We're working on building out a WYSIWYG for drawing policies on a map (or drop on GeoJSON/SHP file to start) + adjusting the rules for each policy - if anyone is interested in testing/helping with iterating on the MVP please feel free to reach out.

[ajturner]

@thekaveman this looks like an interesting project. I would suggest looking at KoopJS. Koop is an open-source tool for converting between API. We use it for ArcGIS Hub (your open data site) to convert Feature Layers to SHP/KML/CSV etc. and could add an output to publish MDS as well.

Let me know what you think about that and collaborating. @ascherkus @schnuerle

[schnuerle]

Louisville is currently hosting this in ArcGIS Online at data.lojic.org. So like @ajturner (hi!) mentioned KoopJS could be used in this case (Santa Monica, Louisville) since it supports ArcGIS Online as a provider. Would need to create an MDS output as seen here.

This could be used for one solution to transform into MDS. Not sure if KoopJS is too heavy of a solution, how easy it is to deploy if packaged up with Docker/Terraform/Kubernetes, or what how the licensing aligns with OMF's requirements.

@contra it looks like you are doing a stand alone WYSIWYG editor to draw boundaries and set policies. What are you using for this, and how will the results be hosted (will it generate a file that the user then places somewhere) and how will the data be kept in sync with changes/updates?

@ascherkus how are you building your GeoJSON to policy converter and how does it handle hosting/updates?

[ascherkus]

@ajturner thanks for the pointer! Yes something like KoopJS can be used to produce MDS policy geographies but I'm less certain about policies (see below).

@schnuerle for the sake of prototyping something super quick I built a command-line version that takes in a shapefile and lets you specify basic policies via switches, and produces a geographies.json and policies.json, leaving static file hosting up to the city. Would be good to get your input on the general approach (is "bring-your-own-static-file-hosting" good enough for cities, or should there be hosting included?)

Regarding updating... I think there are a few separate things to tackle.

1) How do you assign UUIDs to geographies so they can be referenced by policies? I decided to use a hash so that the same input GIS data would produce the same resulting UUID, but it could be random as well.

2) If geographies are changed / updated, how should you go about safely updating geographies.json knowing that policies.json may/may not depend on them? Given policies are immutable, I decided that geographies.json is also append-only.

3) How do you assign a UUID to a policy? Again, random here can work.

4) How do you define a policy that references a geography? I used command-line switches for prototyping, but this is where a WYSIWYG tool could also work. As I mentioned, Shapefile metadata is another option but that would mean defining a separate standard for mapping between metadata and MDS Policy, which doesn't seem desirable.

5) How to update policies.json? Policies are immutable / append-only and reference old ones via prev_policies. This implies that the creation of any new policy requires the currently published version of the policy as input data (or some other access to the entire history of policies).

Given all of the above I'm inclined to suggest that:

• Shapefiles are only good for defining the initial geographies.json file and for possibly appending to it / creating new UUIDs that can be referenced by policies
• Policies should be defined using a tool that may be completely separate from how the geographies are defined
• Policies may use a separate database as the "source of truth" - but may also rely on the currently published version as the source of truth
• For hosting on, say, an S3 bucket I'd recommend enabling object versioning given the static files are overwritten when updated

[schnuerle]

Hi commenting on this to say there are a few new things that may help out here.

One is that MDS is on 1.0.0 which aligns many of our vehicle state terms. It also defines geographies within Policy and the city creates the UUIDs for these. That way policies can reference geographies by ID.

Two is that we are working on 1.1.0 which will move geographies to a top level API so they can be referenced across MDS. It also includes Stops (docks, parking) in Policy.

@ascherkus if you are still working on this, I'd love your thoughts on #500 and the other updates in 1.1.0, and for you to use 1.0.0 which answers many of your previous questions.

[schnuerle]

Note we do have some companies working on something like this for the MDS Policy equivalent endpoints in CDS Curbs which includes specifying geographic areas and the curb policies and rules for each in public data feeds. Once some of those launch we can think about it again for MDS.