[core] geometry@0.8.0 / geojsonvt@6.0.0

[yhahn]

geometry.hpp-based geojsonvt.

• Shape annotation tests are failing. I need to dig into this
• Update all platform build configs
• Tests passing, IRL test with glfw-app
• Remaining code adjustments

---

geometry-0.8.0

• rebase in geometry 0.8.0
• update geojson-vt dep

---

• Code review

[jfirebaugh]

These should all take their argument as const __ & to avoid copying, and use the CamelCase aliases defined below.

[yhahn]

Shape annotation tests were failing without this clamp -- the maxZoom passed here is the map's mapZoom (20). I need to dig further in master to understand what's changed (was geojson-vt-cpp clamping this?)

[brunoabinader]

This looks similar to the issue I am debugging in #5517. I've previously lowered the maximum zoom range for AnnotationSource from 22 to 18 alleviate the issue of disappearing annotations in z19 here.

[jfirebaugh]

util::clamp<uint8_t>(maxZoom, 0, 18)

[mourner]

@brunoabinader can you check if this fixes that maxZoom issue?

[brunoabinader]

I think we can replace this auto& with a const auto&.

[brunoabinader]

@brunoabinader can you check if this fixes that maxZoom issue?

Just did a rebase of my patches from #5517 on top of this branch. I removed the zoom clamping introduced by @yhahn otherwise the app crashes inside GeoJSONVT's getTile:

#0  0x00007ffff56f9418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff56fb01a in __GI_abort () at abort.c:89
#2  0x00007ffff5d3284d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff5d306b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff5d30701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff5d30919 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x000000000089bbf4 in mapbox::geojsonvt::GeoJSONVT::getTile (this=0x227a1b0, z=20 '\024', x_=167740, y=405294)

Although the unit test I introduce passes (all zoom levels returns non-empty features when queried with queryRenderedFeatures) - I've noticed erratic annotation behavior as shown:

This comes along with a console filled with [DEBUG] {mapbox-glfw}[OpenGL]: Buffer doesn't contain elements output. This weird behavior is also present also without my patches applied.

[yhahn]

Once 🍏 this PR will be ready for another review! Here are some known issues/open questions remaining:

• geojsonvt maxzoom issue - determine if this work should wait until @brunoabinader's annotation maxzoom PR fix lands.

Strictness changes

Determine what to do about two known API behavior changes:

• Shape annotation API now must receive closed rings for polygons to render correctly. There's no validation/assertion in place for this, and the behavior of this has changed from master. (https://github.com/mapbox/mapbox-gl-native/blob/geojsonvt/platform/default/glfw_view.cpp#L275-L276)
• geojson.cpp is now stricter and requires a properties key when parsing GeoJSON features. (Add properties value to achieve valid geojson mapbox-gl-test-suite#120)

Question: do we need to smooth these changes out for developers or should we nudge them toward more strictness?

cc @jfirebaugh @mourner @brunoabinader

[mourner]

Shape annotation API now must receive closed rings for polygons to render correctly.

What that the rendering issue you were seeing earlier? For the annotations API, it would be easy enough to close any unclosed polygon rings, right?

geojson.cpp is now stricter and requires a properties key when parsing GeoJSON features.

Note that features with properties: null are still a valid GeoJSON.

[yhahn]

What that the rendering issue you were seeing earlier? For the annotations API, it would be easy enough to close any unclosed polygon rings, right?

Yes. I started to poke at this but it looks like a slippery slope to me -- we would need to add an early closed-ring validator + corrector for fixing any polygons/multipolygons (ie. before shape annotations are passed to geojsonvt for clipping.) Do we do this elsewhere in mbgl?

Note that features with properties: null are still a valid GeoJSON.

Yep, this condition is handled properly.

[yhahn]

After re-reading the discussion on #5517 I think we should land this first (get fully up to date on geojson-vt) and then I can reroll @brunoabinader's testcase and test.

[mourner]

C++ should deduct the return type so this can be just return { ... }, right?

[mourner]

Looked through the code and this looks great to me! Looking forward to this being merged. I'll follow-up with supercluster.hpp integration after that.

[springmeyer]

The value in each visitor here could be passed by const & to avoid an unneeded copy. That said, the compiler will likely optimize away the copy so its not certain my suggestion will run any faster.

[jfirebaugh]

Shape annotation API now must receive closed rings for polygons to render correctly.

My sense is this will be an unexpected / breaking change for users and we should retain the loose API for annotations. We've never documented the annotations API as requiring closed rings or strict GeoJSON geometry.

geojson.cpp is now stricter and requires a properties key when parsing GeoJSON features. (mapbox/mapbox-gl-test-suite#120)

In contrast this seems like an acceptable change. It's reasonable to require a GeoJSON source have valid GeoJSON data. Making the parser more conformant can be construed as a bug fix. And use of GeoJSON sources is low in any case.

[jfirebaugh]

It's awkward to be unable to directly compose mapbox::geojson::convert and mapbox::GeoJSONVT::GeoJSONVT. We should add a GeoJSONVT constructor that accepts mapbox::util::variant<geometry, feature, feature_collection>. cc @mourner

[jfirebaugh]

s/emplace_back(point.x, point.y)/emplace_back(point)/g

[1ec5]

Shape annotation API now must receive closed rings for polygons to render correctly.

This is fine from the iOS and macOS SDKs’ perspective: for compatibility with MapKit, we’ve documented a requirement that MGLPolygon be closed, and the behavior is undefined otherwise.

[yhahn]

@jfirebaugh ready whenever you have a chance for another 👀 Only major change besides the cleanup from notes is the addition of the ring-closer for fill annotations:

• dd8ceb4

[jfirebaugh]

Ring closing should only apply to polygons and multipolygons, not line strings.

[1ec5]

8ca8e2c updates the MGLFeature documentation in the iOS and macOS SDKs to reflect the fact that a feature identifier may be one of several types, not necessarily an NSNumber. We deliberately made the identifier as broadly typed as possible (id, amusingly enough) in anticipation of this change, so no backwards compatibility issues are expected.