Usually, when I can, I offer a layer to join on a Geoserver, for example, through a WMS or WFS service.
However, this time, its not the case. I am asked to provide a REST web-service method where among the attributes returned is a road (a line) that will sometimes interest the caller (and he will want to display it on a map), but most of the times he won't use it.
How should I return that line that depicts the road ? I will return a String, its quite sure, I think.
Should I encode it like Postgis does, for example ?
LINESTRING(0 0, 1 1, 2 1, 2 2) ?
What is the good practice when you have to return in a String attribute some geographical data, in a non-geographic web-service ?
Thanks
I'd suggest GeoJSON format and MongoDB as a back end storage. Though you may wrap geometries from Postgis into GeoJSON either. It allows to store additional attributes and can be rendered by Google API or Bing API or QGIS at user front end.
Related
According to the Geoserver documentation: https://docs.geoserver.org/master/en/user/services/wms/reference.html#getfeatureinfo it is preferred to use the WFS GetFeature service over WMS GetFeatureInfo as literally cited:
The GetFeatureInfo operation requests the spatial and attribute data for the features at a given location on a map. It is similar to the WFS GetFeature operation, but less flexible in both input and output. Since GeoServer provides a WFS service we recommend using it instead of GetFeatureInfo whenever possible.
I have been looking for a way to request all matching features for a lat/lng point and the shape of a layers geometry via WFS GetFeature. I can't find it and the cql_filter combiantion with within or intersects won't get me any further. Any good documeantion or examples someone has to share?
Don't know if you are still needed, but just provides for others who need.
WFS GetFeature request feature with lat/lng literal:
{youHost}/geoserver/wfs?service=WFS&version=1.0.0&request=GetFeature&typeName={yourTypeName}&srsName=EPSG:4326&maxFeatures=10000&format_options=callback:getJson&cql_filter=INTERSECTS(geom, POINT ({long} {lat}))
Greetings fellow SO users,
I am extracting data with import.io from a site which contains city names. What I want to accomplish is to get the coordinates to each city from Nominatim and finally create/get a JSON response which contains the city name and the corresponding coordinates for each.
So I basically need to use the result from one API as the input for another (Nominatim).
Or in other words: feed a JSON list of city names to OSM's Nominatim and get back the coordinates to each city.
I wonder if this is even possible or what other options I have. Finally this would be used with leaflet to put some markers at a map.
There are tutorials for Nominatim, how to query etc. but only one query at a time. Is it even possible to query a whole list of places?
What you want to achieve in here is what we call Chained APIs. So you will need two APIs, where the input of the second one is the output of the first one.
In this case you will need some custom processing between the two APIs. From the first API you are getting the city name and from here you need to generate a list of URLs in the format http://nominatim.openstreetmap.org/search?q=CITY&format=xml one per each CITY.
After that you can use the Bulk Extract feature in import.io and pass the whole list of URLs to be queried against the API.
It seems to me that REST has clean and clear semantics for basic CRUD and for listing resources, but I've seen no discussion of how to handle large lists of resources. It doesn't scale to dump an entire database table over the network in a resource-oriented architecture (imagine a customer table with a million customers!), especially if you only need a few items. So it seems that some semantics should exist to filter, map and reduce a list of resources on the server-side.
So, do you know any tried and true ways to do the following kinds of requests in REST:
1) Retrieve just the count of the resources?
I could imagine doing something like GET /api/customer?result=count
Is that how it's usually done?
I could also imagine modifying the URL (/api/count/customer or /api/customer/count, for example), but that seems to either break the continuity of the resource paths or inflict an ugly hack on the expected ID field.
2) Filter the results on the server-side?
I could imagine using query parameters for this, in a context-specific way (such as GET /api/customer?country=US&state=TX).
It seems tricky to do it in a flexible way, especially if you need to join other tables (for example, get customers who purchased in the last 6 months).
I could imagine using the HTTP OPTIONS method to return a JSON string specifying possible filters and their possible values.
Has anyone tried this sort of thing?
If so, how complex did you get (for example, retrieving the items purchased year-to-date by female customers between 18 and 45 years old in Massachussetts, etc.)?
3) Mapping to just get a limited set of fields or to add fields from joined tables?
4) More complicated reductions than count (such as average, sum, etc.)?
EDIT: To clarify, I'm interested in how the request is formulated rather than how to implement it on the server-side.
I think the answer to your question is OData! OData is a generic protocol for querying and interacting with information. OData is based on REST but extends the semantics to include programatic elemements similar to SQL.
OData is not always URL-based only as it use JSON payloads for some scenarios. But it is a standard (OASIS) so it well structured and supported by many APIs.
A few general links:
https://en.wikipedia.org/wiki/Open_Data_Protocol
http://www.odata.org/
The most common ways of handling large data sets in GET requests are (afaict) :
1) Pagination. The request would be something like GET /api/customer?country=US&state=TX&firstResult=0&maxResults=50. This way the client has the freedom to choose the size of the data chunk he needs (this is often useful for UI-based clients).
2) Exposing a size service, so that the client gets to know how large the data set is before actually requesting it. The service would be something like
GET /api/customer/size?country=US&state=TX
Obviously the two can (and imho should) be used together, so that when/if a client (be it mobile or web or whatever) waints to fill its UI with content, he can choose what's the best data chunk size based also on the size of whole data set (e.g. to avoid creating 100 pages for the user to navigate).
My understanding of REST is that anything that does not change state to the underlying system (e.g. query) should be a GET request. This also means that query parameters have to be put into the URI like so:
api/SomeMethod/Parameter1/{P1:double}/Parameter2/{P1:double}
or as query strings as discussed here:
REST API Best practice: How to accept list of parameter values as input
Sometimes the query may require a lengthy vector (number of x/y points). How do I overcome the length problem of URIs here? Should I just use a POST? Thanks.
If the vector really is big enough to start worrying about you should really consider moving it out of the query params and represent it as a RESTful resource.
For example, create a collection at:
api/Vector
Then your API clients can POST their large vectors and then in another request refer to it by a single id number.
This reduces the size of the query length drastically, abides by REST, and allows for these vectors to be easily reused. If you are worried about storage you can expire vectors after 30 minutes or longer.
Another option is to go down the JSON-LD road which is similar except you don‘t host the vectors. You just provide an #context object and API clients will host the vector on their own server and reference it to your API by URL in a query parameter.
We are creating a service to perform conversions from one format to another. Examples of conversions are currencies, distances, times, languages, etc. In our case it is geographic points (for example from decimal degrees latitude/longitude to degrees-minutes-seconds latitude/longitude).
Typically a RESTful resource has an analogous OO concept that is persistent on the server side that can be CRUDed (I know this is only part of what makes something RESTful), but in the case of a simple service that converts things, that doesn't necessarily exist. How would one make this RESTful? Currently we have some like this:
To get the list of supported formats one can do this:
GET /coordinates/formats
Which would return a list of formats, including, for example DD and DMS (decimal degrees and degrees-minutes-seconds).
One can then turn around and perform a conversion like so:
POST /coordinates/DD/as/DMS
In this example one would pass a representation of decimal degrees (as JSON or some other format) in the request body, and receive a representation of degrees-minutes-seconds in the response body.
This of course works, but feels unRESTful, in particular because the same URI is used over and over for different inputs (different decimal degrees). The trick is probably to really concentrate on what the resource being manipulated it. Perhaps its a "Conversion":
POST /coordinate/conversions
The body might take in the a value, its format, and the desired output. However, the URI is still the same for all resources...
Thoughts?
I would suggest using parameters and GET. I also would switch path elements and make /conversions your root-resource, as conversion is your "domain-core".
Main reasons are:
From api-client perspective above is easier to use (no POST payload, very easy to test/try-out). Client friendliness is one of the highest priorities for api-design.
GET fits better because you don't "change" anything on the server side but rather convert things.
GET /conversions/coordinate?input=xxx&format=yyy
I like your approach to give back metadata with /conversions/formats. It makes formats easy to lookup and your api more self-explainable. The respective data then forms the possible value for 'format'-parameter from above call.
Or are you storing conversion (which would favor state-changing POST method)?