Create Polygon layer on GeoServer using SQL View Query - geoserver

I am drawing polygon on map using openlayer and storing geojson into sql server DB and From Stored geojson i want to create polygon layer on GeoServer and again using wms request to reflect polygon image tile on Map.
So draw on map and storing into db working fine.
Table column EntityJson look like
{
"LatLong": {
"Type": "string",
"Value": "{ \"type\": \"Polygon\", \"coordinates\": [ [ [ -76.2890625, 58.07787626787517 ], [ -95.625, 50.28933925329178 ], [ -84.72656249999999, 41.244772343082076 ], [ -62.22656249999999, 43.32517767999296 ], [ -56.6015625, 48.45835188280866 ], [ -53.78906249999999, 56.9449741808516 ], [ -63.28125, 62.91523303947614 ], [ -76.2890625, 58.07787626787517 ] ] ] }"
}
}
and EntityType is "Area".
But for Next flow to call WMS request on client side for that i'm trying to create polygon Layer by using sql view query on GeoServer so that dynamic take geojson from db based on where EntityType="Area".
But i didn't get how to create sql view query for polygon layer to get geojson data from SqlDB table column EntityJson.
Please can anyone tell me. How to get polygon geojson from table column and create polygon layer on GeoServer by using sqlview query.
Thanks.

The only way to do this is to use string replacement to construct a WKT polygon definition from the JSON which is going to be slow and error-prone.
A better way is to not store GeoJSON in the database but instead store polygons. The easy way to do this is to use OpenLayers WFS-T support to send the features to GeoServer which will then write them correctly into the database (in a vendor-neutral way should you later change databases) and will be able to access them via the WMS interface with no extra effort.
Alternatively, if you have to use GeoJson as a transport format then you should probably look at a NoSQL database like mongoDB which is also usable as a data store in GeoServer.

Related

nestjs +graphQL - nested response shape for data from same table

I am trying to create a nestjs + graphql API which would pull the data from database based on user's request. I am following code first approach. I have to expose an API which would return the below nested response shape, though the all data are from single table.
Table Columns: EmployeeNo, departmentId, DepartmentName
Expected Response Shape:
{
EmployeeNo
Department {
departmentId,
DepartmentName
}
}
I used TypeORM and trying to figure out how to have nestjs+graphql return response shape like above hen all the fields are available in single table as different columns. Do I need to have two entities pointing to same table? will it work?
Any suggestion would be helpful. Thanks in Advance!

How to implement a partial resource rest api?

In order to limit the size of my REST API answers, I want to implement the Google performance tip: using the fields query string parameter to do partial resources.
If I have a full answer GET https://myapi.com/v1/users
[
{
"id": 12,
"first_name": "Angie",
"last_name": "Smith",
"address": {
"street": "1122 Something St.",
"city": "A city"
..and so on...
}
},
... and so on
]
I will be able to filter it GET https://myapi.com/v1/users?fields=first_name
[
{
"id": 12,
"first_name": "Angie"
},
... and so on
]
The concept is pretty easy to understand, but I can't find an easy way to implement it!
My API resources are all design the same way:
use query string parameters for filtering, sorting, paging.
call a service with that parameters to do a SQL request (only the WHERE condition, the ORDER BY condition and the LIMIT are dynamic)
use a converter to format data back to JSON
But when using this new fields parameter, what do I need to do? where do I filter the data?
Do I need to filter only the JSON output? But I will make (in that example) an unwanted JOIN query on address table and fetch unwanted fields in the users table.
Do I need to make a dynamic SQL query to fetch exactly the requested fields and add the JOIN only when the end user need it? Then the converter will have to be smart to convert only the available fields in the SQL query.
In my opinion, this second solution will produce a code extremely dynamic, extremely complex and difficult to maintain.
So, how do you implement such REST API with partial resource feature? What are you best practice in that case?
(I'm a PHP developer, but I don't think it's relevant for that question)
If your backend is doing
GET https://myapi.com/v1/users
which results in SQL:
select * from users
which you then turn into JSON, can you not just do:
GET https://myapi.com/v1/users?fields=first_name,surname,email
get all the required fields (rough idea of PHP implementation):
$fields = split(",", $_GET["fields"]);
$sql = "select ";
foreach ($fields as &$field) {
// do a check to see if the field is ok first...
if (checkField($field)) {
$sql += field + "," // deal with commas
}
}
$sql += " from users";
to build SQL like:
select firstname,surname,email from users
and turn that limited dataset to JSON?

(Ember.js) How to save Sideloaded data from ajax call?

Good day!
Just want to ask on how to create a JSONAPISerializer for an ajax call?
From what I understand on the docs. I must first create a model before I can make a JSONAPISerializer. But I need to call a custom endpoint that is not listed as my model.
My goal is to pushPayload all the sideloaded data coming from my endpoint. but the problem is :
{
"data":[
{
"type":"promotions-verify", <----- it's not an actual model
"attributes":{
"cart-items-discount-in-cents":21900
},
"relationships":{...}, <---- sideloaded data that I want to push on ember-data
}],
"included": [] <---- sideloaded data that I want to push on ember-data
}
Is there a reason you can't make a model for promotions-verify? That would be the cleanest way to implement loading in the side-loaded data, since Ember would handle much of the serialization/pushing to the store for you.
If that isn't possible and you make an ajax request, you may need to map the relationships and included payloads to match up with one another (Lodash _.map() could work well for this). Then you can manually push that data (pushPayload) to the Ember store, while ensuring that the items you're pushing also have models and serializers.
Also, I'm not sure if this was accidental, but your example payload doesn't conform to JSON API standards – the relationships object should be nested within data. This will affect how Ember serializes the data, as it's expecting:
{
"data": [{
"id": 1,
"type": "promotions-verify",
"attributes": {},
"relationships": {}
}],
"included": []
}

How do I avoid n+1 queries with Spring Data Rest?

Question. How do I avoid n+1 queries with Spring Data REST?
Background. When querying Spring Data REST for a list of resources, each of the resulting top-level resources has links to the associated resources, as opposed to having the associated resources embedded directly in the top-level resources. For example, if I query for a list of data centers, the associated regions appear as links, like this:
{
"links" : [ {
"rel" : "self",
"href" : "http://localhost:2112/api/datacenters/1"
}, {
"rel" : "datacenters.DataCenter.region",
"href" : "http://localhost:2112/api/datacenters/1/region"
} ],
"name" : "US East 1a",
"key" : "amazon-us-east-1a"
}
It is pretty typical, however, to want to get the associated information without having to do n+1 queries. To stick with the example above, I might want to display a list of data centers and their associated regions in a UI.
What I've tried. I created a custom query on my RegionRepository to get all the regions for a given set of data center keys:
#RestResource(path = "find-by-data-center-key-in")
Page<Region> findByDataCentersKeyIn(
#Param("key") Collection<String> keys,
Pageable pageable);
Unfortunately the links this query generates don't overlap with the links that the data center query above generates. Here are the links I get for the custom query:
http://localhost:2112/api/regions/search/find-by-data-center-key-in?key=amazon-us-east-1a&key=amazon-us-east-1b
{
"links" : [ ],
"content" : [ {
"links" : [ {
"rel" : "self",
"href" : "http://localhost:2112/api/regions/1"
}, {
"rel" : "regions.Region.datacenters",
"href" : "http://localhost:2112/api/regions/1/datacenters"
}, {
"rel" : "regions.Region.infrastructureprovider",
"href" : "http://localhost:2112/api/regions/1/infrastructureprovider"
} ],
"name" : "US East (N. Virginia)",
"key" : "amazon-us-east-1"
}, {
"links" : [ {
"rel" : "self",
"href" : "http://localhost:2112/api/regions/1"
}, {
"rel" : "regions.Region.datacenters",
"href" : "http://localhost:2112/api/regions/1/datacenters"
}, {
"rel" : "regions.Region.infrastructureprovider",
"href" : "http://localhost:2112/api/regions/1/infrastructureprovider"
} ],
"name" : "US East (N. Virginia)",
"key" : "amazon-us-east-1"
} ],
"page" : {
"size" : 20,
"totalElements" : 2,
"totalPages" : 1,
"number" : 1
}
}
The challenge seems to be that the data center query returns links that aren't particularly informative once you already understand the shape of the data. For example, I already know that the region for data center 1 is at /datacenters/1/region, so if I want actual information about which specific region is involved, I have to follow the link to get it. In particular I have to follow the link to get the canonical URI that shows up in the bulk queries that would allow me to avoid n+1 queries.
The reason Spring Data REST works like this is the following: by default, we assume every application repository a primary resource of the REST service. Thus, if you expose a repository for an entity's related object you get links rendered to it and we expose the assignment of one entity to another via a nested resource (e.g. foo/{id}/bar).
To prevent this, annotate the related repository interface with #RestResource(exported = false) which prevents the entities managed by this repository from becoming top level resources.
The more general approach to this is starting with Spring Data REST letting you expose the resources you want to get managed and default rules applied. You can then customize the rendering and links by implementing ResourceProcessor<T> and registering your implementation as Spring bean. The ResourceProcessor will then allow you to customize the data rendered, links added to the representation etc.
For everything else, manually implement controllers (potentially blending into the URI space of the default controllers) and add links to those through ResourceProcessor implementations. An example for this can be seen in the Spring RESTBucks sample. The sample project uses Spring Data REST to manage Order instances and implements a custom controller to implement the more complex payment process. Beyond that it adds a link to the Order resource to point to the manually implemented code.
Spring Data REST will only create the representation you describe if the serializer that is configured inside the Jackson ObjectMapper is triggered by seeing a PersistentEntityResource, which is a special kind of Resource that is used inside Spring Data REST.
If you create a ResourceProcessor<Resource<MyPojo>> and return a new Resource<MyPojo>(origResource.getContent(), origResource.getLinks()), then the default Spring Data REST serialization machinery will not be triggered and Jackson's normal serialization rules will apply.
Note, however, that the reason Spring Data REST does associations the way it does is because it's very difficult to arbitrarily stop traversing an object graph when serializing to JSON. By handling associations the way it does, it guarantees that the serializer won't start traversing an object graph that is N levels deep and become much slower in performance and in the performance of the representation going over-the-wire.
Ensuring that Jackson does not try to serialize a PersistentEntityResource, which is what it's doing in the default configuration, will ensure that none of the Spring Data REST handling of associations is triggered. The down side to this, of course, is that none of Spring Data REST's helpers will be triggered. If you still want links to the associated resources, you'll have to make sure you create those yourself and add them to the outgoing plain Resource.

What must my Kendo datasource schema look like?

given this json?
[
{
"CompanyId":20,
"CompanyName":"Walmart",
"CompanyContacts":[
{
"CompanyId":20,
"FirstName":"Bob",
"LastName":"Green",
"Email":"bob#test.com",
"Phone":"1234567",
"IsActive":false
}
]
}
]
The KendoUI datasource schema.Model does not currently support nested json or json with related entities. It needs flat data. Hopefully in the future the schema.Model will support mapping complex json to flat in the model definition. However you can still use complex data in the grid you just can't define it in a schema.Model definition.
The mapping is actually done in the field definitions of the grid.
In addition see schema docs you can parse your data using the schema.parse or schema.data functions to manually transform your nested data into flat data.
Here is a fiddle example with your data
{
field : "CompanyContacts[0].FirstName",
title: "First Name"
}
Also note, if you don't need parent record CompanyName and CompanyID since you have CompanyID in your CompanyContacts in the way your data is currently defined then you can use the data attribute of the schema to indicate the starting point of your records like so
schema : {
model: mySchema,
data: "CompanyContacts"
},

Resources