ol.parser.GeoJSON: identifier is dropped

[fredj]

http://geojson.org/geojson-spec.html#feature-objects

[bartvde]

LGTM @fredj I need to do the same for other parsers
Please merge if Travis says it's okay.

[fredj]

Forgot to mention that if the properties already contains an id it will be overwritten.

[bartvde]

This makes me wonder if we should have a fid again like in OL2, which was separate from the attributes.
@fredj what do you think?

[ahocevar]

We do not need a distinction between internal id and fid, because we use goog.getUid for the internal id.

[bartvde]

hey @ahocevar I was talking about a distinction between an attribute named 'id' and the fid (I am not 100% sure if e.g. GML allows this but I think it does).

If I understand @fredj correctly with this approach the fid would override any property named 'id' on the feature already.

Or should we map fid to the internal id instead?

[ahocevar]

Mapping the feature id to the internal id would at least be awkward, if not
impossible.

Storing the fid (or id, not sure what the better name would be) as a member
(without a getter) would be fine I think.

Either way, we will need the server's feature id if we use a tile based bbox strategy - for keeping track of edits and for fetching and rendering data from non tile aware feature servers, so we can keep track of features that we already have in the client side store.

[ahocevar]

Looking into this now. Maybe we can do something similar to what we did with the default geometry.

[ahocevar]

@bartvde, @fredj: Would #733 be an acceptable alternative approach?

[bartvde]

I like this approach @ahocevar

Sent from my iPhone

On May 23, 2013, at 6:17 PM, ahocevar notifications@github.com wrote:

@bartvde, @fredj: Would #733 be an acceptable alternative approach?

—
Reply to this email directly or view it on GitHub.

[fredj]

agree that #733 is a better approach