Re: [Geoserver] Question about PostgreSQL and JSON or HStore

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: [Geoserver] Question about PostgreSQL and JSON or HStore

Hi Leonardo,
you should asks these questions on the pertinent devel list, in this case it's going
to be 90% of the work in GeoTools so I'm cc'ing it, please subscribe to it before
following up with the discussion, and keep the thread on the list.

So, about hstore, as far as I understand it, it's really nothing more than a Java
Map equivalent, so I'd go an map it to the Map Java type.
And this poses some questions... 

The first is, the JDBCDataStore maps to SimpleFeature, which would become
"not so simple" (we have a similar concern with a feature request asking to parse 
arrays out of JSON btw). 
Anyways, it does not look so bad that we would have to rewrite
the store to support complex features either, at least imho...
And here I need feedback from other developers too, but I believe the jump to
the difficulties and slowness of using complex features is not warranted in this case.
Fo reference, we already have nested features sneaked in at the JDBCStore level, when we do joins
(the result is a feature with some attributes whose value is another SimpleFeature).

So let's assume we create a SimpleFeature with a Map<String, String> in
one of its fields, to do that, one would have to update this class for the mapping:

Adding a simpler mapping, for UUID, was done in this commit, it might get you started:

Then we have the actual reading... not sure what ResultSet.getObject will give you back for
a hstore in this method:

If it's not a Map, you might need to roll your own ConverterFactory/Converter implementation, 
you can use the Oracle date converter as a template, here is class and SPI registration:

This should be it for reading (make sure you have tests for every bit of code you added) without filtering.
And then you need to add support for filtering agaisnt HStore entries, assuming you want to use properties
like "myHStoreAttribute/myHStoreKey", you'll probably have to modify this class so that it writes the right sql:

Then it's the turn of output generation. Nothing uses a Map yet, so you're on greenfield, and you'll have
to add support for each and every output you need.

Rendering and filtering wise, the properties of the map need to be made accessible, so I guess you'll
need to write your own PropertyAccessor... and I'm not sure how that can work, people that
have worked on complex features might want to chime in here.

Finally, you have the WFS output formats in GeoServer, none of them knows about Map, you'll
have to upgrade each one of them in a different way I'm afraid.
XML wise, I believe you'll want to to map the Map property to xs:Any, and then modify the GML
encoders to handle that. On the master series the GML encoding of simple features is delegated to the set of classes emanating from this one:

And then there are the other formats too... shapefile, csv, geojson, excel, and so on... each one will likely
need a differen strategy to handle a map with variable content.

It's going to be quite a bit of work, hopefully the discussion on the list here will make some things a bit clearer.
Oh, don't forget to read the contribution instructions about copyright assignment, developing on master, 
tests, coding conventions and so on:


On Thu, Jul 30, 2015 at 8:59 PM, Leonardo Graterol <[hidden email]> wrote:

I'm sorry to bother you.

I read this discussion about HStore support in Geoserver where you suggested that the feature could be added to Geoserver if someone had the time to do it.

I really need HStore support in Geoserver for a LARGE project I'm working and I'd be willing to contribute if you could point me in the right direction in the source code.


Leonardo Graterol Uquillas

Desarrollador de Software

56 2 2829 5027 | 56 2 2829 5000

San Sebastián 2952, piso 3, Las Condes, Santiago, Chile

Cuide el medio ambiente, no imprima este mensaje de no ser necesario

GeoServer Professional Services from the experts! Visit for more information.

Ing. Andrea Aime 
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.


The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.



GeoTools-Devel mailing list
[hidden email]