support new streetmix metric plan about 3dstreet HOT 4 CLOSED

I suggest to change once in one place of the code all the width values ​​in the object with the data received from the streetmix API. So as not to convert to meters everywhere where necessary. @kfarr what do you think about this?
Because, the processSegments function in aframe-streetmix-parser recieve only part of recieved JSON with segments data. But the schemaVersion, as well as units, are at a higher level in recieved JSON.
That is, there will be no need to change the structure of existing code. And remove the conversion of feet to meters everywhere. And moving it to the moment the JSON response is received from the API in streetmix-loader component

from 3dstreet.

More notes and sample API responses for new metric responses:

PR #486. Tested with all cases from here streetmix/streetmix#2900

from 3dstreet.

I'll change tests also

from 3dstreet.

Just sharing notes testing with a streetmix staging server providing metric responses

Testing technique, load the 3dstreet app and type the following in console:

newEl = document.createElement('a-entity')
newEl.setAttribute('streetmix-loader', 'streetmixAPIURL: https://streetmix-staging.herokuapp.com/api/v1/streets?namespacedId=295')
parentEl = document.querySelector('#street-container')
parentEl.appendChild(newEl)

Behavior on 3dstreet.app (production) using OLD parser, parsing the NEW streetmix metric API response. This is using old parser that does not support metric, therefore we expect this to look incorrect, and it does!

Behavior on github.3dstreet.org with NEW streetmix metric API response which supports the new metric api is correct:

Behavior on github.3dstreet.org with OLD streetmix imperial API response:

Therefore both imperial and metric responses work as expected on the new release. I think we're good!

from 3dstreet.