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

Provide a GeoJSON serialization and deserialization utility #3630

Closed
tobrun opened this issue Jan 20, 2016 · 10 comments
Closed

Provide a GeoJSON serialization and deserialization utility #3630

tobrun opened this issue Jan 20, 2016 · 10 comments
Assignees
Labels
feature iOS Mapbox Maps SDK for iOS macOS Mapbox Maps SDK for macOS
Milestone

Comments

@tobrun
Copy link
Member

tobrun commented Jan 20, 2016

This is something that has already been discussed multiple times but was not ticketed out yet.
Our SDK should expose an API so our users can work with GeoJSON.

Since those discussions, GeoJSON support has landed natively in #2161.
I'm not really sure how that translates to this requirement:

  • should we use that API and expose it in Android/iOS SDK?
  • should we implement parsers/builders etc in the Android/iOS SDK ourselves?
    • We used android-geojson library in Android Raster SDK.
    • We could consider using a library like mattt/GeoJSONSerialization for iOS
@tobrun tobrun added iOS Mapbox Maps SDK for iOS Android Mapbox Maps SDK for Android feature request labels Jan 20, 2016
@tobrun tobrun added this to the android-v4.0.0 milestone Jan 20, 2016
@1ec5
Copy link
Contributor

1ec5 commented Jan 20, 2016

We could consider using a library like mattt/GeoJSONSerialization for iOS

GeoJSONSerialization converts GeoJSON into MapKit-specific types, which are incompatible with our iOS SDK. We could derive a Mapbox-compatible library from it, however.

@friedbunny
Copy link
Contributor

Serializing JSON can be a definite pain (ugh, Swift), but there are a variety of third-party libraries out there for the folks who need to do it... so I'm not sure that we have to provide this ourselves for every user.

@1ec5
Copy link
Contributor

1ec5 commented Jan 20, 2016

I can see the value-add for something like GeoJSONSerialization, though. Ordinary JSON comes with no semantics, so using a generic JSON library conjures up memories of raw XML parsing and validation using DTDs and XML Schemas. 😁 By contrast, a GeoJSON-specific library can convert to actual Mapbox SDK types.

For iOS, I think it makes more sense right now to have an independent GeoJSON-to-MGL* library rather than folding the APIs directly into the Mapbox iOS SDK. A developer using React Native Mapbox GL would want to use a more idiomatic React Native component anyways.

@1ec5
Copy link
Contributor

1ec5 commented Aug 26, 2016

Note that basic GeoJSON support has landed in the native SDKs, in the form of GeoJSON sources and more-or-less GeoJSON-compatible geometry classes. This ticket remains open to track ideas for streamlining GeoJSON-related workflows. For example, a built-in GeoJSON (de)serialization feature (think MGLGeoJSONSerialization on iOS and macOS) is now eminently feasible.

@1ec5 1ec5 changed the title GeoJSON support for our SDK users Provide a GeoJSON serialization and deserialization utility Aug 26, 2016
@tobrun
Copy link
Member Author

tobrun commented Oct 20, 2016

obsolete, closing

@tobrun tobrun closed this as completed Oct 20, 2016
@1ec5 1ec5 removed the Android Mapbox Maps SDK for Android label Oct 20, 2016
@1ec5
Copy link
Contributor

1ec5 commented Oct 20, 2016

For iOS and macOS, an MGLGeoJSONSerialization utility would still be desirable. Reopening and removing the Android label.

@1ec5 1ec5 reopened this Oct 20, 2016
@1ec5 1ec5 added macOS Mapbox Maps SDK for macOS runtime styling and removed runtime styling labels Oct 20, 2016
@1ec5 1ec5 self-assigned this Dec 12, 2016
@1ec5 1ec5 added this to the ios-v3.4.0 milestone Dec 12, 2016
@1ec5
Copy link
Contributor

1ec5 commented Dec 12, 2016

Serialization and deserialization methods are being added in #7377. These methods live on MGLShape rather than a standalone MGLGeoJSONSerialization class, because deserializing a GeoJSON data object can only result in a kind of MGLShape, whereas NSJSONSerialization may return anything from a dictionary to a string (if fragments are allowed).

The methods being added in #7377 work with NSData objects containing GeoJSON string data, because working with data read in or being written out to a file is the most likely use case for this API. NSJSONSerialization can be composed with MGLShape methods to get Foundation-typed collection classes if needed, at a slight performance cost. If this cost turns out to be a problem, we can revisit adding additional methods to MGLShape to work with NSDictionary directly.

@nitrag
Copy link
Contributor

nitrag commented Dec 12, 2016

Ok some of your conversation is over my head but just wanted to add my 2 cents.

Currently I'm appending data to the map as the user pans around.

  1. Ajax request to Server. GeoJSON response as STRING.
  2. Use SwiftyJSON to parse the String. Return (Swifty)JSON object.
  3. Retrieve GeoJSON source as (NS)Data. Convert it to (Swifty)JSON object. Loop through and merge the two JSON's into new a object. Return (NS)Data.
  4. Set the GeoJSON Source to the newly merged Data in Step 4.

It would be really cool to just be able to pass a GeoJSON string, with an optional append parameter set to true to the GeoJSON source. (append:false would replace)

geoJSONsource.setGeoJSON(string: geojsonString, append: true)

@1ec5
Copy link
Contributor

1ec5 commented Dec 12, 2016

You'll need to call MGLShape(data:encoding:) to convert the new GeoJSON data (no need for SwiftyJSON) into an MGLShape. Then you can get the MGLShapeCollection (or MGLShapeCollectionFeature) stored in MGLShapeSource.shape, add to its list of shapes, and set MGLShapeSource.shape` to the modified collection.

Since this will be a common use case, we should have an example of it. /cc @friedbunny

@1ec5
Copy link
Contributor

1ec5 commented Dec 14, 2016

Fixed in #7377 on the iOS SDK v3.4.0 release branch.

@1ec5 1ec5 closed this as completed Dec 14, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature iOS Mapbox Maps SDK for iOS macOS Mapbox Maps SDK for macOS
Projects
None yet
Development

No branches or pull requests

6 participants