Parsin JSON like { "type" : "Feature", "id" : 137, ... } fails currently ESRI ArcGIS REST seems to create this kind of GeoJSON.

This fixes an issue brought up by @mikhailswift, @colek42 and @nlacey on https://github.com/paulmach/go.geojson/pull/4 (thank you).

An ID can be either a string or a number. In order to support both marshalling and unmarshalling of those types changing ID to a generic interface type.

The user will then need to call something like f.ID.(float64) or f.ID.(string) to get the value they need. This is consistent with how feature properties are handled.

All it took was changing the signature from (x *Type) to (x Type). Added json.Mashal test for both *Type and Type.

This required (current entered infinite loop) to rewrite feature & feature_collection MarshalJSON. It now mirrors geometry’s implementation (doesn’t mutate caller).

Made the tests more stringent.

Signed-off-by: Frédéric Miserey [email protected]

Hi @paulmach

Great library, i use it quite a bit and it works great. I have a question, let's say I have a bunch of records in WKT (some points, poly, lines, etc) and I would like build a geojson out of them.

What would you say is the best way to extract the geometry from WKT in a way that this library will easily understand it? Do you have a recommendation?

Thanks again!

Jose

Hello,

go.geojson is functional for me, however I'd like to add additional custom JSON data to the output, seperate from the FeatureCollection. I have both geojson and event data (for the locations) successfully outputting via REST API as two different routes. However I'd like to combine them so that the JSON has two main children: a 'FeatureCollection' and 'Events' containing my custom events data.

My first approach has been to create a new struct to encapsulate them both, like so:

// GeoLocationsEvents type
type GeoLocationsEvents struct {
	Locations FeatureCollection `schema:"locations"`
	Events []Event `schema:"events"`
}

However I get a type incompatibility error when it comes time to make use of the fc object that go.geojson is outputting.

This is my router function:

func (a *App) getLocationsEventsGeoJSON(w http.ResponseWriter, r *http.Request) {

 // This successfully returns a complete FeatureCollection (using go.geojson) and a complete Events object.
    fc, events, err := getLocationsEvents(a.DB, start, count)
    if err != nil {
        respondWithError(w, http.StatusInternalServerError, err.Error())
        return
    }


// Now, I attempt to merge the two using my new struct.
// My intention is to pass it to a final function which marshals the json.
	var locationsEvents GeoLocationsEvents

// THIS CAUSES AN ERROR: cannot use fc (type *geojson.FeatureCollection) as type *FeatureCollection in assignment
	locationsEvents.Locations = fc
	locationsEvents.Events = events

      // The final function call before outputting to client. If I test with fc or events directly, they both work spitting JSON to the browser. However I want them to be combined.
       respondWithGeoJSON(w, http.StatusOK, locationsEvents)
}

func getLocationsEvents(db *sql.DB, start, count int) ([]Location, []Event, *geojson.FeatureCollection, error) {

	var events = []Event{}
	elements := map[int]int{}
	fc := geojson.NewFeatureCollection()

// and much more... excluded from post

}

It would be really nice if one could easily create a copy of a Geometry without having to worry about any references. I see two ways to achieve this, either by modifying the constructors for new Geometries or by adding a Copy() method.

Currently NewPolygonGeometry for example takes the polygon [][][]float64 and simply uses it. However that means if something modifies the passed polygon it will also modify the geometry.

For the reason I'd suggest to either create a copy using something like this whenever a new polygon is created

cp := make([][][]float64, len(polygon))
copy(cp, polygon)

An alternative would be to explicitly create a new copy of a geometry using a method in the form of func (g *Geometry) Copy() *Geometry (or Clone) returning an exact copy, with now more references to the original.

The second option would I think would both be cleaner as well as allowing people to choose whether they really want to allocate a new slice.

I am trying to build go.geojson and I'm getting the following:

example_test.go:6:2: cannot find package "git.tech.rz.db.de/streckenkunde40/thirdparty/github/paulmach/go.geojson" in any of:
	D:\Tools\Go\src\git.tech.rz.db.de\streckenkunde40\thirdparty\github\paulmach\go.geojson (from $GOROOT)
	D:\Users\BKU\AlexeyValikov\go\src\git.tech.rz.db.de\streckenkunde40\thirdparty\github\paulmach\go.geojson (from $GOPATH)

Any hint how to deal with it?

Unfortunately go is strict regarding semver. I just did a go get on this package and then checked your releases. A plain go get downloaded v1.3.1 as it's the latest semver compliant tag (vn.n.n), and ignored v1.4 due to the missing last digit. v1.4 should be tagged as v1.4.0 for go 1.11+ with module support to work.

See https://github.com/golang/go/issues/24476 for some comments where it doesn't appear that this will change, in particular:

This should be fixed. I think vgo should just completely ignore non-canonical semver tags (v1 or v1.0 instead of v1.0.0) in repos.

Hello!

I added a Get_Boundingbox() method to the Feature structure. I realize this is sort of maybe a little out of the projects scope comparing with the other methods, but only slightly, and I would find it incredibly useful.

You may ask why mutate the BoundingBox at the feature level? When at the geometry level Get_BoundingBox() returns a BoundingBox ([]float64) rather than mutate the Geometry, this is because if you change both you have the same bounding box in two places which isn't cool for serialization to text, and I thought it would be more useful at the top level of a feature rather than within a geometry (although one could argue it makes more sense there).

Implementation driver.Value interface for correct writing Geometry type into DB. When using PostGIS a spatial column would need to be wrapped in ST_GeomFromGeoJSON.

It's an interesting issue which I faced with the Feature.Properties json tag.

Properties  map[string]interface{} `json:"properties"

We're storing the GeoJSON as JSONB into postgres and when the following RawJSON was unmarshalled, it'd be 'null' for properties tag RawJSON:

                    {
                        "geometry": {
                            "coordinates": [
                                14,
                                12
                            ],
                            "type": "Point"
                        },
                        "type": "Feature",
                        "properties": {}
                    }

Unmarshalled to

{ "geometry": {"type": "Point", "coordinates": [14, 12]}, "properties": null}]}

which is a invalid GeoJSON format.