search

earthcubearchitecture-project418 / services

RPC services package for Project 418
0 stars 2 forks source link

Add Additional Properties to GeoJSON Results from /api/v1/spatial/search/object Call #8

Open ericlingerfelt opened 6 years ago

ericlingerfelt commented 6 years ago

It is possible to add additional properties to each result? Currently there is only URL. But it would be great to get Provider Name and Index so that the JavaScript data structures are reusable.

fils commented 6 years ago

@ericlingerfelt

This is more difficult... this is a KV store using the URL as the key and GeoJSON as the value.

To do what you ask I would have to do something like 1) inject that information at the time of indexing 2) look up the info on each resource returned by the KV call.. then insert the feature properties

2 might be a performance hit.. so I would likely do this in the indexer..

Let me take a look and see how much effort it would take and get back to you on this one. There really is no "index" in the spatial index... since it's just a geohash. We could put in the text "index" name the resource is associated with.

ericlingerfelt commented 6 years ago

@fils

OK. We can just leave it the way it is for now. It would be nice to add things in the future matching provider to each result so that users can toggle them on and off the map by provider.

fils commented 6 years ago

ok.. that is a cool use case.. I'll be back to the spatial code soon.. let me look at it and see what I can do.

ericlingerfelt commented 6 years ago

@fils

Is it possible for the client to parse the web domain of the provider form the URL? In that case you could include the url domain as a property returned from typeahead maybe? Then the client could parse the provider from the URL for the spatial search call.

fils commented 6 years ago

@ericlingerfelt

I am trying to avoid any logic in code to resolve data attributes. Additionally in some case we get a situation where the org domain is foo.org but the data domains are data.foo.org. This could happen for services, etc. So I want to avoid having to have too much logic to deal with cases.

Even if done client side, I am gun shy of the pattern.

I have the solution based on a generated prov graph and VoID and I'm convinced it will do all we need and avoid any logic or parsing needs. It will be later next week before I can implement it though. It would allow a client to make the connection you seek and still rely on facility provided data or process provenance data.

ericlingerfelt commented 6 years ago

@fils

I agree. That was a method of last resort. I'll work with what is currently coming from the spatial search call.