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
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:
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
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
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
