thomersch / grandine Goto Github PK
View Code? Open in Web Editor NEWProcessing geo data is no fun. Grandine changes this.
License: Apache License 2.0
grandine's People
Contributors
Stargazers
Watchers
grandine's Issues
GeoJSON output should follow RFC7946 winding order
The GeoJSON specification is picky about winding order.
Grandine should only produce GeoJSON that winds according to rfc7946. There is code that is already supposed to do that, but output from grandine still has rings that aren't rewound correctly.
To reproduce, run the geojsonhint command line tool or geojsonlint.com on a tile produced by grandine.
> geojsonhint 43.geojson
20:1 warning Polygons and MultiPolygons should follow the right-hand rule
60:1 warning Polygons and MultiPolygons should follow the right-hand rule
512:1 warning Polygons and MultiPolygons should follow the right-hand rule
552:1 warning Polygons and MultiPolygons should follow the right-hand rule
1004:1 warning Polygons and MultiPolygons should follow the right-hand rule
1044:1 warning Polygons and MultiPolygons should follow the right-hand rule
1494:1 warning Polygons and MultiPolygons should follow the right-hand rule
1536:1 warning Polygons and MultiPolygons should follow the right-hand rule
1583:1 warning Polygons and MultiPolygons should follow the right-hand rule
1626:1 warning Polygons and MultiPolygons should follow the right-hand rule
1673:1 warning Polygons and MultiPolygons should follow the right-hand rule
1716:1 warning Polygons and MultiPolygons should follow the right-hand rule
1763:1 warning Polygons and MultiPolygons should follow the right-hand rule
1806:1 warning Polygons and MultiPolygons should follow the right-hand rule
1853:1 warning Polygons and MultiPolygons should follow the right-hand rule
1916:1 warning Polygons and MultiPolygons should follow the right-hand rule
1979:1 warning Polygons and MultiPolygons should follow the right-hand rule
2061:1 warning Polygons and MultiPolygons should follow the right-hand rule
2131:1 warning Polygons and MultiPolygons should follow the right-hand rule
2203:1 warning Polygons and MultiPolygons should follow the right-hand rule
2493:1 warning Polygons and MultiPolygons should follow the right-hand rule
2782:1 warning Polygons and MultiPolygons should follow the right-hand rule
3071:1 warning Polygons and MultiPolygons should follow the right-hand rule
3599:1 warning Polygons and MultiPolygons should follow the right-hand rule
3877:1 warning Polygons and MultiPolygons should follow the right-hand rule
4175:1 warning Polygons and MultiPolygons should follow the right-hand rule
4285:1 warning Polygons and MultiPolygons should follow the right-hand rule
4392:1 warning Polygons and MultiPolygons should follow the right-hand rule
4443:1 warning Polygons and MultiPolygons should follow the right-hand rule
4508:1 warning Polygons and MultiPolygons should follow the right-hand rule
4559:1 warning Polygons and MultiPolygons should follow the right-hand rule
4609:1 warning Polygons and MultiPolygons should follow the right-hand rule
4653:1 warning Polygons and MultiPolygons should follow the right-hand rule
5585:1 warning Polygons and MultiPolygons should follow the right-hand rule
6515:1 warning Polygons and MultiPolygons should follow the right-hand rule
6562:1 warning Polygons and MultiPolygons should follow the right-hand rule
6613:1 warning Polygons and MultiPolygons should follow the right-hand rule
6662:1 warning Polygons and MultiPolygons should follow the right-hand rule
⚠ 38 warnings
Remove GEOS Dependency by implementing own clipping algorithm
Unfortunately my attempt of implementing polygon clipping (intersecting bbox and polygon) failed miserably, because I kept having issues with real world examples. To be able to process polygons I started using GEOS, the geospatial library. The big downside of this approach is that GEOS is not very fast as it needs cgo to call its C-interface which has a high overhead for this kind of usage. Using C libraries also makes cross-compilation more cumbersome.
I would like to have a pure Go polygon intersection implementation. An implementation of a third-party package could be viable, if the process of converting the data structure doesn't have a too big overhead.
Simplification After Clipping in Tiler
It seems you are doing simplification after clipping and this can produce some strange artifacts often in your results from tiling. My suggested flow would be:
- Reprojection to zoom level tile coordinates
- Simplification
- Clipping Tile (consider how this affects validity)
- Translation of coordinates to specific tile
- Encoding
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.