-
-
Notifications
You must be signed in to change notification settings - Fork 6k
Adds support for altitude and 3D GeoJSON #1822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This commit adds a third parameter to the L.LatLon class for specifying
altitude. This is in turn stored in the `.latitude` property for the LatLng
instance. Latitude property will only be set if the latitude parameter is not
undefined, this is done in order to ensure backwards compability.
```javascript
var latlng = new L.LatLng(10, 20, 30);
console.log(latlng.altitude); // prints '30' to the console
```
Similar functionality has been added to L.GeoJSON coordsToLatLng() and
latLngToCoords() methods in order to handle import and export of 3D GeoJSON.
```javascript
var geoJSON = {
type: 'Feature'
,properties: {}
,geometry: {
type: 'Point'
,coordinates: [20, 10, 30]
}
}
var layer = new L.GeoJSON();
layer.addData(geoJSON);
console.log(layer.getLayers()[0].getLatLng().altitude);
```
`NB` It is important to notice that no logic has been added in order to prevent
latitude and longitude to change without appropirate change in altitude – this
must be handled by the application.
|
Thanks for the pull, but you didn't provide any use cases for this. Why would anyone want Leaflet to understand 3D coordinates if it's not a 3D library? |
|
The use case for this is a routing application I am building for my employee (https://github.com/Turistforeningen/leaflet-routing). Our backend routing service returns a 3D GeoJSON LineString for each new, or changed, waypoint. When the user is happy with his route all the separate LineStrings are glued together into one big GeoJSON LineString and sent and stored in a database. This too should be represented as 3D GeoJSON as we want the altitude for the whole route. Keeping the altitude, instead of just discarding them which is how LeafletJS treats them today, makes import and export of 3D GeoJSON a breeze. As of now one has to keep track of all the altitudes separately of the LineStrings which creates extra housekeeping work for the developer. This pull simply ensures that altitude, if it exists, is not just discarded :) Also, the GeoJSON specification for positions states the following:
This new feature is fully backwards compatible! As you can see I took the liberty of making two separate versions of all the GeoJSON unit tests, one for 2D and one for 3D, in order to ensure complete backwards comparability in all cases. The code change itself is only a very few lines of code (4 lines removed and 12 lines added). |
|
Thanks for the explanation! @tmcw @jfirebaugh thoughts? |
|
Seems fine to me, though the property should be named |
|
Seems fine to me, though it does seem sort of like there should be |
|
@tmcw I don't think we should create another entity in the API for such a rare use case that is not used anywhere inside the library. An optional argument seems fine. |
|
@tmcw I only think adding this as a new class would make sense if Leaflet ought to implement a complete 3D API. |
|
Will be merged for 0.7. |
|
Merged finally. Thanks! |
|
Thank you Vladimir!
|
This pull adds a third parameter to the L.LatLon class for specifying altitude. This is in turn stored in the
.altproperty for the LatLng instance. Latitude property will only be set if the latitude parameter is not undefined, this is done in order to ensure backwards compability.Similar functionality has been added to L.GeoJSON coordsToLatLng() and latLngToCoords() methods in order to handle import and export of 3D GeoJSON.
NBIt is important to notice that no logic has been added in order to prevent latitude and longitude to change without appropirate change in altitude – this must be handled by the application.