Skip to content
This repository has been archived by the owner on May 24, 2024. It is now read-only.

Some outputs say "matched" but they are not assigned a reference id #11

Open
chmnata opened this issue Mar 25, 2019 · 3 comments
Open
Labels

Comments

@chmnata
Copy link
Contributor

chmnata commented Mar 25, 2019

It only happens in the centreline table so far. Basically the output from shared streets will be the indication that the link was matched, along with NULL values for the rest of the output fields.

The only case we have seen so far are for centreline segments with the geo_id of 30104621. This same geo_id is not in gis.centreline, it is only in gis.centreline_both_dir or gis.centreline_one_way. The segment is on Melita Crescent and seems to be pretty normal, so we do not understand why it was not matched.

image

@chmnata
Copy link
Contributor Author

chmnata commented Mar 25, 2019

We currently created a list null_matched in our function conflator.ipynb to store these cases. These cases are not being inserted in the final output table.

@chmnata
Copy link
Contributor Author

chmnata commented Mar 27, 2019

The original geojson for two linestrings (both direction for one street segment - Melita Cres) that got matched but returned no reference_id or any attributes:
Original Geojson

Returned as this:

{
  "name": "ShareStreets_ID_here",
  "results": [
    {
      "type": "FeatureCollection",
      "features": []
    }
  ]
}

@emilyeros
Copy link

Kevin is tackling this. this is related to the conversion from MultiLineStrings to LineStrings. we match individual LineString features and need to split up the MultiLineStrings into individual features before we attempt matching. i think the properties are getting lost in that cleaning process.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants