Nuno,
anything that can reduce code duplication sounds attractive.
One problem with app-schema is that, because of the complexity of the
test fixtures, much of the test coverage is in GeoServer app-schema-test
test-only submodules. Are you familiar with these, and have you
considered how you will test the new MongoDB complex feature
functionality? Even if your changes are confined to the MongoDB modules
in GeoTools, you might find a test-only module in GeoServer quite useful.
Kind regards,
Ben.
On 02/11/16 23:21, Nuno Oliveira wrote:
> Hi Ben,
>
> Thanks for the feedback and sorry for the delay in my reply, but I had
> to check a few things first.
>
> After some more thinking and play with the code I came to the conclusion
> that if create a
> standalone MongoDB store I will have to duplicate a lot of code from the
> original MongoDB code. So I
> investigated the possibility to instead extend the original MongoDB
> store to support the app-schema integration.
>
> This in practice means having an extra parameter that will tell us that
> we are working with complex features
> and handle complex features needs when needed in the workflow, i.e. in
> the filtering and when reading
> from Mongo.
>
> Regards,
>
> On 10/27/2016 04:11 AM, Ben Caradoc-Davies wrote:
>> Nuno,
>>
>> that looks like a good idea to me. app-schema has already been
>> restructured once to accommodate the
>> modules/unsupported/app-schema/webservice backend. Much of the complex
>> feature support was later pulled into the complex module. These
>> changes should make app-schema easier to extend. +1 for reusing
>> app-schema machinery.
>>
>> +1 to add a new unsupported module for this work. Would you like to
>> put it inside the unsupported/app-schema folder or at the top level in
>> unsupported?
>>
>> Kind regards,
>> Ben.
>>
>>
>> On 26/10/16 12:43, Nuno Oliveira wrote:
>>> Hi,
>>>
>>> The idea here is to be able to output a MongoDB collection content as
>>> complex features.
>>>
>>> For those wondering, how MongoDB store works right now, it basically
>>> flats the JSON
>>> elements and ignore collections (geometries are treated as special case
>>> and properly encoded).
>>>
>>> Consider that we have in a MongoDB a collection called stations that
>>> contains the measurements
>>> of several meteorological stations:
>>>
>>> db.stations.insert({
>>> "id": "1",
>>> "geometry": {
>>> "coordinates": [
>>> 50.0,
>>> 60.0
>>> ],
>>> "type": "Point"
>>> },
>>> "name": "station 1",
>>> "contact": {
>>> "mail": "[email protected]"
>>> },
>>> "measurements": [
>>> {
>>> "name": "temp",
>>> "unit": "c",
>>> "value": 35.5
>>> },
>>> {
>>> "name": "wind",
>>> "unit": "km/h",
>>> "value": 110.5
>>> }
>>> ]
>>> })
>>>
>>> db.stations.createIndex({
>>> geometry: "2dsphere"
>>> })
>>>
>>> The current MongoDB store will output something like this for a
>>> GetFeature request:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <wfs:FeatureCollection xmlns="http://www.opengis.net/wfs";
>>> xmlns:gml="http://www.opengis.net/gml"; xmlns:mongo="mongo"
>>> xmlns:wfs="http://www.opengis.net/wfs";
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> xsi:schemaLocation="mongo
>>>
>>> http://localhost:8092/geoserver/mongo/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=mongo%3Astations3
>>>
>>>
>>> http://www.opengis.net/wfs
>>> http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd";>
>>> <gml:boundedBy>
>>> <gml:null>unknown</gml:null>
>>> </gml:boundedBy>
>>> <gml:featureMember>
>>> <mongo:stations3 fid="580f7cb4c1ed909ae180819a">
>>> <mongo:geometry>
>>> <gml:Point
>>> srsName="http://www.opengis.net/gml/srs/epsg.xml#4326";>
>>> <gml:coordinates cs="," decimal="." ts=" "
>>> xmlns:gml="http://www.opengis.net/gml";>10,60</gml:coordinates>
>>> </gml:Point>
>>> </mongo:geometry>
>>> <mongo:id>1</mongo:id>
>>> <gml:name>station 1</gml:name>
>>> <mongo:contact.mail>[email protected]</mongo:contact.mail>
>>> </mongo:stations3>
>>> </gml:featureMember>
>>> </wfs:FeatureCollection>
>>>
>>> As you can see the the list of measurements was ignored and the JSON
>>> attributes were flatted (contact.mail).
>>>
>>> If MongoDB stations collection was encoded as complex features the
>>> result should have been something similar to this instead:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <wfs:FeatureCollection ...>
>>> <st:featureMember>
>>> <st:StationFeature gml:id="1">
>>> <st:name>station 1</st:name>
>>> <st:contact>
>>> <st:mail>[email protected]</st:mail>
>>> </st:contact>
>>> <st:measurement>
>>> <st:name>temp</st:name>
>>> <st:unit>c</st:unit>
>>> <st:value>35.5</st:value>
>>> </st:measurement>
>>> <st:measurement>
>>> <st:name>wind</st:name>
>>> <st:unit>km/h</st:unit>
>>> <st:value>110.5</st:value>
>>> </st:measurement>
>>> <st:geometry>
>>> <gml:Point
>>> srsName="http://www.opengis.net/gml/srs/epsg.xml#4326";>
>>> <gml:coordinates>50.0,60.0</gml:coordinates>
>>> </gml:Point>
>>> </st:geometry>
>>> </st:StationFeature>
>>> </gml:featureMember>
>>> </wfs:FeatureCollection>
>>>
>>> The associated schema was attached to this mail.
>>>
>>> App-schema can work with simple stores creating complex features by
>>> composing several simple features,
>>> in the case of MongoDB we actually want to be able to map the complete
>>> JSON tree. This is the main reason
>>> why MongoDB current store will not work with app-schema, we would only
>>> have access to the flat attributes.
>>>
>>> The idea were would be to create a complex MongoDB store capable to
>>> answer app-schema queries by having
>>> access to all the JSON object, this store will only be usable by
>>> app-schema and cannot be used in a standalone way.
>>> This way we will reuse all app-schema already implemented machinery and
>>> avoid to duplicate a lot of complex code.
>>>
>>> I already perform some tests and was able to get complex features with
>>> simple mappings:
>>>
>>> <typeMappings>
>>> <FeatureTypeMapping>
>>> <sourceDataStore>data_source</sourceDataStore>
>>> <sourceType>st</sourceType>
>>> <targetElement>st:StationFeature</targetElement>
>>> <attributeMappings>
>>> <AttributeMapping>
>>> <targetAttribute>
>>> st:StationFeature
>>> </targetAttribute>
>>> <idExpression>
>>> <OCQL>jsonSelect("stations.id")</OCQL>
>>> </idExpression>
>>> </AttributeMapping>
>>> <AttributeMapping>
>>> <targetAttribute>st:name</targetAttribute>
>>> <sourceExpression>
>>> <OCQL>jsonSelect("stations.name")</OCQL>
>>> </sourceExpression>
>>> </AttributeMapping>
>>> <AttributeMapping>
>>> <targetAttribute>st:contact/st:mail</targetAttribute>
>>> <sourceExpression>
>>> <OCQL>jsonSelect("stations.contact.mail")</OCQL>
>>> </sourceExpression>
>>> <isMultiple>true</isMultiple>
>>> </AttributeMapping>
>>> </attributeMappings>
>>> </FeatureTypeMapping>
>>> </typeMappings>
>>>
>>> In this example I used a filter function for explicitly select the deep
>>> JSON content.
>>>
>>> The most difficult part is the mapping of the JSON lists as nested
>>> objects through feature
>>> chaining, the way I found to do it right now is to use a filter function
>>> that tell
>>> explicitly the path of the sub-collection:
>>>
>>> <AttributeMapping>
>>> <targetAttribute>st:measurement</targetAttribute>
>>> <sourceExpression>
>>> <OCQL>jsonSelectCollection("stations.id",
>>> "stations.measurement")</OCQL>
>>> <linkElement>st:SituationMeasurement</linkElement>
>>> <linkField>FEATURE_LINK[1]</linkField>
>>> </sourceExpression>
>>> <isMultiple>true</isMultiple>
>>> </AttributeMapping>
>>>
>>> When performing a query we visit the filter I to see if we can found the
>>> explicit sub collection.
>>>
>>> With this approach we will have a strange MongoDB complex store that
>>> only makes sense to use
>>> with app-schema but we will reuse app-schema machinery and all this work
>>> will be contained in
>>> a single module.
>>>
>>> Opinions on this are very welcome, I know that this is a lot to digest
>>> and the subject is a little bit complex :)
>>>
>>> Regards,
>>>
>>> Nuno Oliveira
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> The Command Line: Reinvented for Modern Developers
>>> Did the resurgence of CLI tooling catch you by surprise?
>>> Reconnect with the command line and become more productive.
>>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>>> http://sdm.link/telerik
>>>
>>>
>>>
>>> _______________________________________________
>>> GeoTools-Devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>
>
--
Ben Caradoc-Davies <[email protected]>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
