Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

[core] geometry@0.8.0 / geojsonvt@6.0.0 #5514

Merged
merged 10 commits into from
Jul 6, 2016
Merged

[core] geometry@0.8.0 / geojsonvt@6.0.0 #5514

merged 10 commits into from
Jul 6, 2016

Conversation

yhahn
Copy link
Member

@yhahn yhahn commented Jun 29, 2016

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

@@ -12,6 +12,16 @@ enum class FeatureType : uint8_t {
Polygon = 3
};

struct ToFeatureType {
FeatureType operator()(mapbox::geometry::point<int16_t>) const { return FeatureType::Point; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

mapbox::geojsonvt::Options options;
options.maxZoom = maxZoom;
options.maxZoom = mbgl::util::clamp((int)maxZoom, 0, 18);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mourner
Copy link
Member

mourner commented Jun 30, 2016

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

return;

AnnotationTileLayer& layer = *data.layers.emplace(layerID,
std::make_unique<AnnotationTileLayer>(layerID)).first->second;

ToGeometryCollection toGeometryCollection;
ToFeatureType toFeatureType;
for (auto& shapeFeature : shapeTile.features) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@brunoabinader
Copy link
Member

@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:

out

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
Copy link
Member Author

yhahn commented Jul 3, 2016

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:

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

cc @jfirebaugh @mourner @brunoabinader

@yhahn yhahn changed the title [notready] geojsonvt @ 6.0.0 geometry@0.8.0 / geojsonvt@6.0.0 Jul 3, 2016
@mourner
Copy link
Member

mourner commented Jul 4, 2016

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
Copy link
Member Author

yhahn commented Jul 4, 2016

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 yhahn changed the title geometry@0.8.0 / geojsonvt@6.0.0 [core] geometry@0.8.0 / geojsonvt@6.0.0 Jul 4, 2016
@yhahn
Copy link
Member Author

yhahn commented Jul 4, 2016

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.

return mapbox::geojson::feature_collection { value };
}
mapbox::geojson::feature_collection operator()(const mapbox::geojson::geometry value) const {
return mapbox::geojson::feature_collection { { value } };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mourner
Copy link
Member

mourner commented Jul 5, 2016

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.

@@ -18,14 +20,30 @@ using namespace mapbox::geojsonvt;
namespace mbgl {
namespace style {
namespace conversion {

struct ToFeatureCollection {
mapbox::geojson::feature_collection operator()(const mapbox::geojson::feature_collection value) const {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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.

ToFeatureCollection toFeatureCollection;
const auto geojson = mapbox::geojson::convert(value);
const auto features = apply_visitor(toFeatureCollection, geojson);
return GeoJSON { std::make_unique<GeoJSONVT>(features, options) };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

GeometryCoordinates coordinates;
coordinates.reserve(geom.size());
for (const auto& point : geom) {
coordinates.emplace_back(point.x, point.y);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@1ec5
Copy link
Contributor

1ec5 commented Jul 5, 2016

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
Copy link
Member Author

yhahn commented Jul 6, 2016

@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:

@jfirebaugh
Copy link
Contributor

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

@yhahn yhahn merged commit 71a3b1d into master Jul 6, 2016
@yhahn yhahn deleted the geojsonvt branch July 6, 2016 21:29
1ec5 added a commit that referenced this pull request Jul 10, 2016
Since #5514, feature IDs may be integers, unsigned integers, floating-point numbers, or strings, not just unsigned integers.
@1ec5
Copy link
Contributor

1ec5 commented Jul 10, 2016

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.

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

Successfully merging this pull request may close these issues.

6 participants