Stefano,
that looks great. Excellent test coverage! I also ran a full GeoServer
build and app-schema online test against postgis and everything passed.
Kind regards,
Ben.
On 17/10/15 06:03, Stefano Costa wrote:
> Hi Ben,
> I changed the implementation as discussed, closed the previous PR and
>
Hi Ben,
I changed the implementation as discussed, closed the previous PR and
opened another one:
https://github.com/geotools/geotools/pull/1000
All in all, I like this version more, the code is simpler and I also added
a test case to prove swe:values can be encoded using isList.
I hope you'll li
On 16/10/15 10:39, Stefano Costa wrote:
>> One other question: will this work with isList?
>> >http://docs.geoserver.org/latest/en/user/data/app-schema/mapping-file.html#islist-optional
> I didn't try, because in my case isList is not really an option as it
> requires that data be stored in a denor
On 16/10/15 10:29, Stefano Costa wrote:
> I didn't really intend to enable mixed content, I'm testing if the target
> element can have mixed content just as an alternative way to determine that
> it can store simple content (in practice, a string).
Ah ha! That makes sense. I had incorrectly assume
On Thu, Oct 15, 2015 at 11:08 PM, Ben Caradoc-Davies
wrote:
> If you can reuse simpleContent, that may keep the code simpler and require
> a smaller adjustment. I think lists of values are simple. The original
> implementation will likely need some improvement.
Will try and do it tomorrow.
Hi Ben and Andrea,
On Thu, Oct 15, 2015 at 10:49 PM, Ben Caradoc-Davies
wrote:
> I am not saying that there is anything wrong with Stefano's
> implementation, just that, in his thoroughness, he has included support for
> mixed content which, if it occurs, indicates the user is doing something
>
On 16/10/15 03:12, Stefano Costa wrote:
> Not sure either, perhaps you can come up with a better name. However, as
> said above, I could force the content to be simple, in which case I might
> as well reuse the "simpleContent" special property that is already taken
> care of by the current code.
I
On 15/10/15 19:24, Andrea Aime wrote:
> Just as a couple of philosophical considerations:
> * GeoServer never tried to be OGC's cop, we normally take the approach of
> allowing whatever is useful in practice
> * Are we sure GML schema implementors are aware of all these little rules,
> and that we
Hi Ben,
On Thu, Oct 15, 2015 at 12:11 AM, Ben Caradoc-Davies
wrote:
> If mixed content is prohibited, would this change your implementation?
>
What if I forced the "unrestricted content" into a string with no XML
elements inside? I could e.g. change the code so that the value is
converted to
On Thu, Oct 15, 2015 at 12:11 AM, Ben Caradoc-Davies
wrote:
> Good. Your code and test coverage are thorough as usual. My main concern
> is that it is too general and may work for cases that should not be
> supported as they are prohibited by the GML encoding rules.
>
Just as a couple of philoso
On 14/10/15 02:31, Stefano Costa wrote:
> I tried to mimic what you did to support complex types with simple content,
> here is the PR:
> https://github.com/geotools/geotools/pull/994
> The reasoning behind it is that if a complex type is derived from
> xs:anyType by extension (not restriction) and
Hi Ben,
sorry for the late reply.
On Fri, Oct 9, 2015 at 12:18 AM, Ben Caradoc-Davies
wrote:
> Have you tried using TargetAttributeNode to set the property to
> gml:CodeType or another type with simple content?
>
Yes, I did, but to no avail.
Writing new code should be a last resort. SWE-spec
Aha! This is the complex-type-with-simple-content problem. I recall
encountering it when adding support for gml:CodeType, which has the same
information model mismatch, but without the complication of an anyType
in the mix.
Have you tried using TargetAttributeNode to set the property to
gml:Co
Dear all,
I'm working on mapping some data stored in a database to the OGC SWE schema
using app-schema.
I'm having troubles mapping to swe:DataArray/swe:values, which is an
element of type swe:EncodedValuesPropertyType, whose definition follows:
/* taken from http://schemas.opengis.net/sweCommon/
14 matches
Mail list logo
