make wzdx spec conform to geojson

[indraneel]

Proposal

I'm working with road closures data @sharedstreets and want to expand on the suggestion in #21 to use GeoJSON for WZDx. GeoJSON is based on JSON (making it very human-readable) and around it is a healthy open source ecosystem. GeoJSON is a geospatial data standard that data consumers are familiar with. GeoJSON can be easily translated into formats like CIFS (#25) as well.

The main idea here is that anything related to the work zone location can be a concern of the GeoJSON Feature's geometry field (a well-defined standard for geospatial data), and anything else (aka the WorkZoneActivity/the Common Core Data Dictionary) can be a concern of the GeoJSON Feature's properties field.

Example GeoJSON WZDx shape

For WZDx:

• at the top level there will be a metadata object that contains the fields in File Header Information
• each item in the features array will have a geometry type of LineString representing the location of the work zone
• each item in the features array will have a properties value that will be contain WorkZoneActivity object—this will be an object with all the properties defined in the Common Core Data Dictionary

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",            
            "geometry": {
                "type": "LineString",
                "coordinates": [
                    [100.0, 0.0],
                    [101.0, 1.0],
                    [102.0, 2.0]
                ]
            },
            "properties": { WorkZoneActivity }
        }
    ],
    "metadata": { File Header Information }
}

In this pull request:

This pull requests modifies the spec to:

• add a section on what GeoJSON is

• add a section on how the WorkZoneActivity object relates to GeoJSON (each Feature has a properties object that will be a WorkZoneActivity object)

• remove latitude/longitude from the BeginLocation and EndLocation DataFrames

• edit full-spec/full-spec.md

• add sample WZDx typescript classes w/ GeoJSON support

• update data-tables/*.md

• update sample-files/

• update images/

[indraneel]

This change is backwards-incompatible, so closing in favor of #40 that is backwards-compatible.

I am open to considering this if backwards-compatibility isn't deemed a requirement.

[mikelmaron]

@indraneel why is there a requirement to make this backwards compatible? didn't think this spec was widely adopted yet, and that we are here to help shape this to be the most useful spec possible. I think GeoJSON would be the natural choice for simplicity and wide adoption.

[kpwebb]

@mikelmaron from the SharedStreets side we're fully in support of GeoJSON as the path forward as but had heard from WZDx team during previous working group meeting that there was a preference for PRs that were backwards compatible, hence adding #40 as an alternative. Just to be clear our preference would be to stick with GeoJSON, as that mirrors how we've handled this in our SharedStreets closures tooling.

[antrim]

Conformance to GeoJSON will make quite a few libraries, validators, and visualization tools available and useful for WZDx users.