Quick Start

[vr00n]

Hi there. We are planning to incorporate the Shared Streets spec into Streets Data Collaborative. Specifically around our Street Quality IDentification project where use Open Street Cam to digitally survey local streets and Bike Lanes.

An idealized SQUID project involves surveying all streets or all bike lanes in a city over some time and then identify the top-n worst quality streets in that city.

A typical challenge in implementing this is identifying a canonical way to express a point on a street as being part of a distinct street segment, consistently.

Ex: Lat/Log = OnStreet between FromStreet ToStreet

We are currently experimenting with various ways to do this programmatically but want to explore using SharedStreets to do this.

Here is the challenge visually. The point (40.006411, -105.279892) needs to be expressed as 10th St. between College St. and Euclid St. OR 10th St. between Euclid St. and College St.

If we were to use google, we would get 1099-1001 10th St which is not ideal.

How would you recommend we do this using the SharedStreets spec.?

Thanks.

Varun

[migurski]

Have you looked at the linear reference objects? I imagine a point like this could be expressed as a distance along an LR, e.g. "50 meters along 10th Street".

[kpwebb]

@migurski and @vr00n we have a linear referencing spec that we're already using for some of our street-linked data sets. It can be used to define a point or a sub-segments. You can check it out here:

https://github.com/sharedstreets/sharedstreets-ref-system/blob/master/proto/linear_references.proto

I think you want to the point reference. Notice that there's also a concept of "binned" linear references for aggregating data. That lets you create an arbitrary number of "bins" along a street that allow you to group data together (e.g. divide the street into ~10m segments and bin data like counts or averages into each sub-segment). For less precise grouped data this could useful!

More detailed docs and examples are in the works (we actually have a UI and javascript code that generates these inside mapbox-gl-js that we're gearing up to release).

Also, in other "quick start" news, we have a new global tile 12z set that's built off of the Feb 5th planet PBF:

https://tiles.sharedstreets.io/12-{x}-{y}.{reference|intersection|geometry|metadata}.pbf

You can open these tiles in JS using the sharedstreets-pbf library, or using the .proto files directly. Again more docs on TK, but would love to rope you all into helping create examples using the tile set!

[dmarulli]

Thanks @kpwebb.

I am working with @vr00n to implement SQUID at scale. He has given a good high-level review of the project, but I just want to bring to the surface what the immediate relevant technical question is here:

We currently have city-scale shapefiles of street segments that we pull programmatically from OSM (using OSMnx) as part of our automated pipeline. We would like to enrich these datasets by assigning each segment a Stable, non-proprietary shorthand ID. At a conceptual level, this seems to be exactly what SharedStreets References is designed for. Additionally, this repo's README states that the SharedStreets referencing system is being released with open-source "tools for generating references from OpenStreetMap and Shapefile data sources".

However looking at the SharedStreets Builder repo, it looks like support for shapefiles does not yet exist. Ideally (for our situation), one could imagine providing a street segment shapefile as an input and receiving a new shapefile with an additional SSR column as an output. Is this functionality on the roadmap?

Another straightforward solution for our situation that comes to mind is provide some sort of array of OSM way and intersection IDs that we get from the shapefiles we already have, and receive the corresponding stable SSRs. This would allow us to join SSR IDs into our tables. Is this functionality on the roadmap?

This endpoint (http://tiles.sharedstreets.io/12-{x}-{y}.{reference|intersection|geometry|metadata}.pbf) returns an AccessDenied message by the way. Maybe I am missing some parameters?

Thanks again. Would love to sync these efforts too.

[kpwebb]

@dmarulli We're moving our work reconciling Shapefiles over to the the conflator tool here:

https://github.com/sharedstreets/sharedstreets-conflator

This is a work in progress but it allows you to map Shapefiles (or other spatial data) to SharedStreets References. We're just going to use the builder for processing very large data sets (e.g. the OSM planet files), to generate the base SharedStreets tiles. We used builder to create the files that are now up on the http://tiles.sharedstreets.io end-point.

You an learn more about these file formats here:

https://github.com/sharedstreets/sharedstreets-ref-system

And see a sample tile set here (note the format of the URL in the readme):
https://github.com/sharedstreets/sharedstreets-sample-data

We in the process of putting together more documents and examples using these tiles, so if you need additional help getting started, let's circle back end of next week and share some additional resources.

[DenisCarriere]

@dmarulli returns an AccessDenied message by the way. Maybe I am missing some parameters?

You're application needs to be able to replace the {x}, {y} & {reference|intersection|geometry|metadata} data fields, for example if you wanted to retrieve the PBF for tile [1145, 1493, 12] (XYZ) the URL would look like this:

https://tiles.sharedstreets.io/12-1145-1493.geometry.pbf

For an easy to use Javascript library that will replace the {x} & {y} parameters, you can use:

https://github.com/DenisCarriere/slippy-tile

The Javascript code would look something like this:

const slippyTile = require('slippy-tile');

const tile = [1145, 1493, 12]; // [x, y, zoom]
const scheme = "https://tiles.sharedstreets.io/12-{x}-{y}.geometry.pbf";
const url = slippyTile(tile, scheme);
url; // => https://tiles.sharedstreets.io/12-1145-1493.geometry.pbf

[i-am-sijia]

Hi @kpwebb

Does the conflator tool https://github.com/sharedstreets/sharedstreets-conflator return global stable SharedStreets References that can be used to link different maps together?

I fed sharedstreets-conflator two shapefiles from different sources, for the same area. I expected the two sets of .reference.json to have some common SharedStreets Reference ids. But that wasn't the case. I guess the conflator is not designed for getting the global SS References by map matching? Is this more of a SS API job? In addition, if the conflator can return reference.json with the corresponding link id from my shapefile, it will be helpful. Let me know if I'm missing something.

Thank you.

[d-wasserman]

Hi @kpwebb,

I think I want to clarify what will be available, on what time lines, and at what level of abstraction so we can start to think about how to help agencies with potential deployments of sharedstreets tiles/references.
When will the Global Tileset be ready? Will we be able to convert into a file based geospatial format such as Shapefile or Geopackage?
Are there any data sets slated to use shared-streets in the near term?
I can move these questions to a new issue if it would help.
Thanks.