Re: [Geotools-devel] app-schema and xs:anyType encoding
Mauro,
your proposal seems like a good idea, and would improve usability where
the encoder should not require explicit direction. I was simply offering
a workaround while I thought about it. :-)
My main concern is the interaction with type conversion. What if an
app-schema mapping uses targetAttributeNode to set an anyType to a
MeasureType or CodeType (or some other complex type that extends a
simple type)? Would this type coercion still be honoured if the encoder
is permitted to use the concrete type of the source value?
I am happy to review any pull request; I would run the full suite of
GeoServer app-schema online tests against postgis. This is the most
comprehensive set of app-schema mapping tests we have. Even offline
tests also have anyType coverage.
Kind regards,
Ben.
On 26/02/15 21:19, Mauro Bartolomeoli wrote:
Hi Ben,
probably you are right, declaring that targetAttributeNode is used in a
wrong way in my usecase, I added it trying to understand why the lcv:class
attribute (declared as xs:anyType) was not encoded in GML. Probably, after
the patch to anyType handling I talk about in my email (that's the main
point of my issue, not the targetAttributeNode usage) it would work also
without it (I will try).
The main issue remains: is it correct to add handling of primitive
(simple) types to xs:anyType bindings and which approach seems better to
you, changing ComplexSupportXSAnyTypeBinding or its parent class
XSAnyTypeBinding?
Any hint is appreciated.
Thanks
Mauro Bartolomeoli
2015-02-25 21:32 GMT+01:00 Ben Caradoc-Davies b...@transient.nz:
Mauro,
targetAttributeNode must be applied to the containing property type
lcv:landCoverObservation[1]/lcv:LandCoverObservation, not the terminal
node. I am not sure exactly what you should use in this case, but please
see these pages for examples:
http://docs.geoserver.org/latest/en/user/data/app-
schema/mapping-file.html#targetattributenode-optional
http://docs.geoserver.org/latest/en/user/data/app-
schema/polymorphism.html#any-type
Kind regards,
Ben.
On 25/02/15 23:24, mauro.bartolomeoli wrote:
Hi,I have an unexpected behaviour in app-schema mappings, when I have to
deal with an attribute declared as xs:anyType.
From my understanding of the xs:anyType meaning, this can be mapped to
simple (xs:string, etc.) or complex types.
Currently if I map an xs:anyType attribute to an xs:string it doesn't get
encoded in the final GML3 document.
This is the mapping configuration:
AttributeMapping
targetAttribute
lcv:landCoverObservation[1]/lcv:LandCoverObservation/lcv:
class
/targetAttribute
targetAttributeNodexs:string/targetAttributeNode
sourceExpression
OCQLUCS2007/OCQL
/sourceExpression
/AttributeMapping
lcv:class is declared in its xsd as xs:anyType.
As you can see I am explicity declaring xs:string as the target attribute
node type, and the app-schema mapping seems to work well with it. The
problem seems to be the encoder, that uses ComplexSupportXSAnyTypeBinding
to encode xs:anyType attributes.
This binding class currently only support ComplexAttribute objects, but
with my mapping the value is a simple String, so it doesn't get encoded at
all.
My idea is to change the encode method to:
1) call super.encode(...) when the value is not a ComplexAttribute
2) implement the encode method in the parent class (XSAnyTypeBinding)
to handle simple value encoding, something like:
public Element encode(Object value, Document document, Element
element)
throws Exception {
if (value != null) {
Text text = document.createTextNode(Converters.convert(value,
String.class));
element.appendChild(text);
}
return element;
}
In alternative I can do all the work in ComplexSupportXSAnyTypeBinding
encode method, without touching XSAnyTypeBinding.
Anyone with app-schema / complex types experience can give me an advice
on this?
Thanks
Mauro
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
---
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003Le 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
[Geotools-devel] Build failed in Jenkins: geotools-12.x #71
See http://ares.opengeo.org/jenkins/job/geotools-12.x/71/changes Changes: [daniele.romagnoli] GEOT-5031: Supporting more time units in NetCDF time axis -- [...truncated 56479 lines...] adding: library/xml/filter.html (deflated 76%) adding: library/xml/internal/ (stored 0%) adding: library/xml/internal/index.html (deflated 71%) adding: library/xml/internal/configuration.html (deflated 71%) adding: library/xml/internal/overview.html (deflated 74%) adding: library/xml/internal/tutorial.html (deflated 77%) adding: library/xml/internal/code.html (deflated 75%) adding: library/xml/internal/bindings.html (deflated 75%) adding: library/xml/resolving.html (deflated 70%) adding: library/xml/style.html (deflated 76%) adding: library/xml/faq.html (deflated 68%) adding: library/xml/geometry.html (deflated 78%) adding: library/coverage/ (stored 0%) adding: library/coverage/grid.html (deflated 74%) adding: library/coverage/index.html (deflated 72%) adding: library/coverage/oracle.html (deflated 66%) adding: library/coverage/netCDF.html (deflated 68%) adding: library/coverage/arcgrid.html (deflated 69%) adding: library/coverage/pyramid.html (deflated 66%) adding: library/coverage/geotiff.html (deflated 69%) adding: library/coverage/multidim.html (deflated 68%) adding: library/coverage/image-collection.html (deflated 67%) adding: library/coverage/gtopo30.html (deflated 67%) adding: library/coverage/internal/ (stored 0%) adding: library/coverage/internal/index.html (deflated 67%) adding: library/coverage/internal/format.html (deflated 67%) adding: library/coverage/grassraster.html (deflated 72%) adding: library/coverage/pgraster.html (deflated 74%) adding: library/coverage/jp2k.html (deflated 64%) adding: library/coverage/arcsde.html (deflated 68%) adding: library/coverage/mosaic.html (deflated 67%) adding: library/coverage/geotiff_new.html (deflated 68%) adding: library/coverage/jdbc/ (stored 0%) adding: library/coverage/jdbc/index.html (deflated 68%) adding: library/coverage/jdbc/oracle.html (deflated 69%) adding: library/coverage/jdbc/ddl.html (deflated 69%) adding: library/coverage/jdbc/performance.html (deflated 71%) adding: library/coverage/jdbc/import.html (deflated 74%) adding: library/coverage/jdbc/mysql.html (deflated 70%) adding: library/coverage/jdbc/prepare.html (deflated 70%) adding: library/coverage/jdbc/db2.html (deflated 69%) adding: library/coverage/jdbc/setup.html (deflated 70%) adding: library/coverage/jdbc/customized.html (deflated 69%) adding: library/coverage/jdbc/jdbc.html (deflated 69%) adding: library/coverage/jdbc/internal.html (deflated 75%) adding: library/coverage/jdbc/faq.html (deflated 69%) adding: library/coverage/jdbc/meta.html (deflated 70%) adding: library/coverage/jdbc/postgis.html (deflated 68%) adding: library/coverage/faq.html (deflated 66%) adding: library/coverage/image.html (deflated 72%) adding: library/coverage/matlab.html (deflated 67%) adding: library/coverage/imageio.html (deflated 68%) adding: library/coverage/coverageio.html (deflated 68%) adding: library/coverage/tools.html (deflated 68%) adding: library/metadata/ (stored 0%) adding: library/metadata/index.html (deflated 68%) adding: library/metadata/geotools.html (deflated 69%) adding: library/metadata/internal/ (stored 0%) adding: library/metadata/internal/index.html (deflated 66%) adding: library/metadata/internal/cache.html (deflated 65%) adding: library/metadata/internal/collections.html (deflated 65%) adding: library/metadata/internal/utilities.html (deflated 82%) adding: library/metadata/metadata.html (deflated 70%) adding: library/metadata/pool.html (deflated 72%) adding: library/metadata/faq.html (deflated 70%) adding: library/metadata/range.html (deflated 82%) adding: library/metadata/text.html (deflated 81%) adding: library/data/ (stored 0%) adding: library/data/index.html (deflated 71%) adding: library/data/datastore.html (deflated 67%) adding: library/data/export.html (deflated 74%) adding: library/data/wfs-ng.html (deflated 67%) adding: library/data/georest.html (deflated 67%) adding: library/data/edigeo.html (deflated 67%) adding: library/data/pregeneralized.html (deflated 79%) adding: library/data/wfs.html (deflated 66%) adding: library/data/csv.html (deflated 67%) adding: library/data/memory.html (deflated 75%) adding: library/data/featuresource.html (deflated 82%) adding: library/data/property.html (deflated 74%) adding: library/data/ogr.html (deflated 71%) adding: library/data/vpf.html (deflated 67%) adding: library/data/internal.html (deflated 68%) adding: library/data/arcsde.html (deflated 69%) adding: library/data/dxf.html (deflated 67%) adding: library/data/faq.html (deflated 68%) adding: library/data/caching.html (deflated 67%) adding: library/data/excel.html (deflated 67%) adding:
[Geotools-devel] axis order blues
Hi, Okay, so according to the geotools documentation CRSes with full URI specification don't suffer from axis order confusions. But I have the following SRS used in a test: urn:x-ogc:def:crs:EPSG:6.11.2:26713 And here's the thing: when running the test in maven, this is North-East, when running the same test in eclipse this is East-North. How on earth could that be possible?? What I've been able to figure out is that when running in maven the CRS is built by DirectEpsgFactory which takes it from a database in epsg-hsql, but in eclipse it is built by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file (which says east-north). So my guess is that this has something to do with the different way that maven and eclipse handle module dependencies. But still, shouldn't it always be North-East when specified with such a URI? It almost seems like a pure gamble which axis order you are going to end up with in geotools. You can force geotools to always use east-north, but you can't do it the other way around! And you can only set that setting once in the beginning of running your java instance, changing it again doesn't guarantee success because of caching crses. Also, I think there is a lot of unnecessary throwing away of axis order going on by using srs strings when there are already methods in place to use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs methods are deprecated, but they are still used everywhere, even in new code, it seems like the deprecations in BoundingBoxImpl are still ignored. In the FilterDuplicatorVisitor, from which most filter visitors are derived, the boundingbox is rebuilt using setSrs() so all CRS information axis order is lost each time a filter is rebuilt with a visitor. I think that could be easily changed. Regards Niels -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] app-schema and xs:anyType encoding
Hi Ben,
probably you are right, declaring that targetAttributeNode is used in a
wrong way in my usecase, I added it trying to understand why the lcv:class
attribute (declared as xs:anyType) was not encoded in GML. Probably, after
the patch to anyType handling I talk about in my email (that's the main
point of my issue, not the targetAttributeNode usage) it would work also
without it (I will try).
The main issue remains: is it correct to add handling of primitive
(simple) types to xs:anyType bindings and which approach seems better to
you, changing ComplexSupportXSAnyTypeBinding or its parent class
XSAnyTypeBinding?
Any hint is appreciated.
Thanks
Mauro Bartolomeoli
2015-02-25 21:32 GMT+01:00 Ben Caradoc-Davies b...@transient.nz:
Mauro,
targetAttributeNode must be applied to the containing property type
lcv:landCoverObservation[1]/lcv:LandCoverObservation, not the terminal
node. I am not sure exactly what you should use in this case, but please
see these pages for examples:
http://docs.geoserver.org/latest/en/user/data/app-
schema/mapping-file.html#targetattributenode-optional
http://docs.geoserver.org/latest/en/user/data/app-
schema/polymorphism.html#any-type
Kind regards,
Ben.
On 25/02/15 23:24, mauro.bartolomeoli wrote:
Hi,I have an unexpected behaviour in app-schema mappings, when I have to
deal with an attribute declared as xs:anyType.
From my understanding of the xs:anyType meaning, this can be mapped to
simple (xs:string, etc.) or complex types.
Currently if I map an xs:anyType attribute to an xs:string it doesn't get
encoded in the final GML3 document.
This is the mapping configuration:
AttributeMapping
targetAttribute
lcv:landCoverObservation[1]/lcv:LandCoverObservation/lcv:
class
/targetAttribute
targetAttributeNodexs:string/targetAttributeNode
sourceExpression
OCQLUCS2007/OCQL
/sourceExpression
/AttributeMapping
lcv:class is declared in its xsd as xs:anyType.
As you can see I am explicity declaring xs:string as the target attribute
node type, and the app-schema mapping seems to work well with it. The
problem seems to be the encoder, that uses ComplexSupportXSAnyTypeBinding
to encode xs:anyType attributes.
This binding class currently only support ComplexAttribute objects, but
with my mapping the value is a simple String, so it doesn't get encoded at
all.
My idea is to change the encode method to:
1) call super.encode(...) when the value is not a ComplexAttribute
2) implement the encode method in the parent class (XSAnyTypeBinding)
to handle simple value encoding, something like:
public Element encode(Object value, Document document, Element
element)
throws Exception {
if (value != null) {
Text text = document.createTextNode(Converters.convert(value,
String.class));
element.appendChild(text);
}
return element;
}
In alternative I can do all the work in ComplexSupportXSAnyTypeBinding
encode method, without touching XSAnyTypeBinding.
Anyone with app-schema / complex types experience can give me an advice
on this?
Thanks
Mauro
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
---
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003Le 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
Re: [Geotools-devel] axis order blues
Niels, I will answer your first question. You are right: this is a classpath difference. The cause is that Maven and Eclipse have different dependency models. Eclipse has no notion of a phase (compile versus test) and no way to exclude transitive dependencies (so test dependencies of other modules always get included on the classpath). gt-epsg-wkt is the problem; how do you make it go away? This is the devious workaround I implemented in 2010 to disable gt-epsg-wkt EPSGCRSAuthorityFactory so that gt-xsd-gml3 unit tests pass in Eclipse: https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml3/src/test/java/org/geotools/referencing/crs/EPSGCRSAuthorityFactory.java https://jira.codehaus.org/browse/GEOT-3112 It may be enough to add gt-xsd-gml3 as a test-phase dependency before all other dependencies. Maven will not include it as a dependency for consumers of your module because it is test-phase only. Eclipse will blindly include it at all times and disable gt-epsg-wkt. There is no META-INF/services SPI file as this is provided by the real implementations. Kind regards, Ben. On 27/02/15 10:52, Niels Charlier wrote: Hi, Okay, so according to the geotools documentation CRSes with full URI specification don't suffer from axis order confusions. But I have the following SRS used in a test: urn:x-ogc:def:crs:EPSG:6.11.2:26713 And here's the thing: when running the test in maven, this is North-East, when running the same test in eclipse this is East-North. How on earth could that be possible?? What I've been able to figure out is that when running in maven the CRS is built by DirectEpsgFactory which takes it from a database in epsg-hsql, but in eclipse it is built by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file (which says east-north). So my guess is that this has something to do with the different way that maven and eclipse handle module dependencies. But still, shouldn't it always be North-East when specified with such a URI? It almost seems like a pure gamble which axis order you are going to end up with in geotools. You can force geotools to always use east-north, but you can't do it the other way around! And you can only set that setting once in the beginning of running your java instance, changing it again doesn't guarantee success because of caching crses. Also, I think there is a lot of unnecessary throwing away of axis order going on by using srs strings when there are already methods in place to use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs methods are deprecated, but they are still used everywhere, even in new code, it seems like the deprecations in BoundingBoxImpl are still ignored. In the FilterDuplicatorVisitor, from which most filter visitors are derived, the boundingbox is rebuilt using setSrs() so all CRS information axis order is lost each time a filter is rebuilt with a visitor. I think that could be easily changed. Regards Niels -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Ben Caradoc-Davies b...@transient.nz Software Engineer Transient Software http://transient.nz New Zealand -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
