Implement 'scale' for geometries

[wilhelmberg]

Splitting into a dedicated issue from #18 (comment)

/cc @david-rhodes @brnkhy

---

Thought this would be quick and started here: BergWerkGIS-implement-scale

But it's not and needs more work.

Friction:

• current workflow: get raw geometries -> clip if needed -> return Point2d list (of type long)
• proposed workflow: get raw geometries and apply scale -> clip -> return generic Point2d list
• implementing scale triggers Point2d to be made generic (<T>): being long currently but by applying scale we most likely would want to get back float or double.
• but getting back T/float/double for geometries conflicts with the clipping (needs long).
  Clipping was always intended to be a temporary solution only, to be removed again after we have feature merging/deduping in place, but I don't expect that any time soon so we have to keep clipping a while longer.
• needs changes in almost all classes and will trigger changes in client code

Ideas:

• concrete implementations of Point2dLong and Point2dFloat
• change workflow: get raw geometries -> apply clipping if needed -> apply scale if needed -> return concrete implementations or Point2d<T>

I have to think a bit about this ...

[wilhelmberg]

@brnkhy @david-rhodes I hacked together a quick working fix: https://github.com/mapbox/vector-tile-cs/tree/BergWerkGIS-implement-scale

All LatLng/GeoJson related stuff is commented - would need more work.

Request a feature like this:

var feat = layer.GetFeature<float>(idxFeat, 0, 1.75f);
                                            ^   ^ scale factor
                                            | clip hard at border

and then feat.Geometry returns a List<List<Point2d<float>> where

• coordinates are clipped at the tile boundary
• coordinates are scaled by 1.75, eg internal coordinates were 10/15, now they are 17.5/26.25

Is this what you need?

[brnkhy]

@BergWerkGIS if you can check the vector2d branch, I'm doing that scaling in VectorFeatureUnity constructor as well. Now doing it in GetFeature would be even better but if it returns List<List<Point2d<float>> I'll have to convert that to Vector3 as well so maybe we can change it to return List<List<Vector3>> ?

I also have another question you might know. Yesterday I realized that traffic vector tile coordinates work different and not in 0-4096 range. They are probably not relative to the tile and scaling them simply doesn't work (converting to wsg84 does though). Do you know about that issue? I asked in traffic channel but haven't got any answer yet.
we can simply check feature name and do wsg84 conversion if it's name=="traffic" but I feel like it's quite a bad way to do it and want to understand how's that working first.

Edit: I just realized ector3 means UnityEngine dependency, we can return Vector2d but that won't change the issue either. So maybe it's just a good idea to do that scaling in unity side? I mean in the sdk of course, we can have an overload to provide that functionality but not use in SDK

[wilhelmberg]

I'll have to convert that to Vector3 as well so maybe we can change it to return List<List>

I suppose Vector3 is Unity specify?
If yes then we cannot return that as we would need a reference to the Unity.dll.

Yesterday I realized that traffic vector tile coordinates work different and not in 0-4096 range.

Have you looked at VectorTileLayer.Extent?
That might help you scale the geometries - ToWgs() takes the extent into account.
Every layer can have a different extent - 4096 is no magic number that applies everywhere.
Bigger extent: higher precision, needs more space.
Smaller extent: lower precision, needs less space.

[brnkhy]

Have you looked at VectorTileLayer.Extent?

Ah ok now this makes sense. I totally didn't know that exists but it'll probably solve the issue right away. Thanks @BergWerkGIS, will edit this if it works out.

Edit: Yep! Worked out beautifully, thanks Willy!

[wilhelmberg]

Done: https://github.com/mapbox/vector-tile-cs/tree/v1.0.4-alpha1