Simplify purpose of sharedstreets-python

[sharedstreets]

Simplify purpose of sharedstreets-python

[migurski]

For my own use, having tools in NodeJS is not actually helpful unless they're truly standalone. Converting PBF to other formats may need to happen in a library context, integrated into another codebase.

[kpwebb]

Just +1 for @migurski point -- I think we need multi-language support, as we want folks to integrate SharedStreets data standards into their internal platforms/data workflows so we can't take a position on language/architecture.

We'll probably rely more on the JS versions (for the time being) for our SharedStreets data workflow/QA process, but doesn't diminish the need for other languages to have parity with client libs.

Just add a near-term justification: full Python support will be crucial for ESRI and QGIS plugins.

[kpwebb]

Going back to #1 let's make a list of key functionality we want to see in client-libs (using the current JS and Python libs as references). Ok with me if these aren't at 100% parity for the moment, but useful as a goal. And we can point to that for future libs in other languages (can see formal Java support useful)

[migurski]

Key functionality I’d expect to see in a client library, with checks for the ones that exist here in Python:

• Protobuf code to access upstream SharedStreets data
• Conversion functions for PBF data into something locally useful:
  • GeoJSON
  • GIS features, such as OGR or ESRI depending on environment
• ID calculation for local data
• Dataset conflation with other local data

Additional stuff that could be interesting depending on client language conventions:

• Ability to serve GeoJSON tiles
• Conversion to NetworkX with OSMnx compatibility, for Python
• Detail reduction by road class clipping
• Ability to map properties or features onto SharedStreets geometries

[migurski]

This issue feels safe to close; hope that’s okay with folks.