FR: is WITHIN .. FEATURE a good idea???

[tomquas]

Is your feature request related to a problem? Please describe. today, WITHIN .. OBJECT returns parts geojson, parts proprietary result sets. this typically asks for parsing and remodeling on client side when building geojson Feature and FeatureCollection – the format lots of 3rd-party libs and servers require to process data. we had to invest dev/test/cpu cycles to convert tile38 result sets to proper geojson. example:

> tile38-cli WITHIN p OBJECTS HASH u2
{"ok":true,"objects":[{"id":"u281_9","object":{"type":"Point","coordinates":[11.3,48]}},{"id":"u281_7","object":{ ...

Describe the solution you'd like ideally for us, WITHIN .. would be capable of returning geojson features conforming to official schema. maybe introduce WITHIN .. FEATURES to keep compatibility with existing deployments? example:

> tile38-cli WITHIN p FEATURES HASH u2
{"ok":true,"objects":[
  {"type": "Feature",
      "properties": { "id": "u281_9" },
      "geometry": {
        "type": "Point",
        "coordinates": [
          11.3, 48.1
        ]
      }
  }, ...
]}

Describe alternatives you've considered only alternative i see is to parse WITHIN .. OBJECT output and construct a new object model conforming to FeatureCollection / Feature[] - lots of cpu heat for for translating tens of thousands of points.

Additional context use case: display points on map using leafletjs.

[tidwall]

Feature and FeatureCollection are pretty standard these days, especially in the JS world. I would think this could be a good candidate for a new Tile38 feature.

[tomquas]

thanks @tidwall, that's good news. i had a first look at the code - i am not a go coder yet, but from what i've seen, scanner.go and json.go should be the places to extend?

[tidwall]

Hey @tomquas. Sorry about the delayed response. I'm a bit slow atm, particularly with new features.

Yes, the object format is written in the scanner.go file.

Also, if you add FEATURES to the WITHIN command, then it must also be supported for the INTERSECTS, NEARBY, and SCAN. And in turn, probably for the GET command too, but as just FEATURE (save the 'S').

One thing to point out is that it's very common for people to already use a Feature as their primary (only) input geojson object, so it should be detected that if the object is already a Feature, then don't wrap it in an additional Feature type for the output.

Finally, I must emphasize that there are two protocol output formats, RESP and JSON that both must be supported.

Oh and finally finally, unit test should be added.

[tomquas]

hey @tidwall, sorry, busy times. i had another look and i get a feeling that the templating code needs some refactoring before this feature fits in. i'm not up to this atm, not enough time to learn go and do this properly. if anybody wants to own this, feel free...