[geotk] Issue with JAXPFeatureTypeReader

johann sorel johann.sorel at geomatys.com
Mon Jun 29 00:49:07 PDT 2015


Hello emmanuel,

Could you send the result of :
feature.getType().toString()
and
feature.toString();


The method : /feature.getType().*getProperties(true)*/
is from the new feature model of SIS and geotk implementation do not 
fully comply with those interfaces yet.
use : feature.getType().*getDescriptors()
*

Johann Sorel
johann.sorel at geomatys.com

On 28/06/2015 23:41, Emmanuel Blondel wrote:
> See the piece of code i have here: 
> https://github.com/openfigis/gems/blob/master/feature/src/main/java/org/fao/fi/gems/feature/FeatureUtils.java#L57
> (see the Java comments where i've indicated what i would have 
> expected, and what i get)
>
> Basically, so far i was identifying the geometry property Type, and 
> retrieving the geometryName (usually "THE_GEOM" for oracle store, but 
> it is likely to change, "the_geom" for postgis).
>
> Up until now i could retrieve with no problem, and then i can retrieve 
> the geometry using /feature.getProperty(geometryName), /but not with 
> the current snapshot.
> /
> /Thanks in advance
> Emmanuel
>
> Le 27/06/2015 02:35, Emmanuel Blondel a écrit :
>> I've finally resolved the issue below.
>>
>> However i still get weird behaviors when retrieving featureType...
>> I can get the featureType well (and print it as table in log 
>> everything is fine...) but:
>> If i looking into the properties by means of: 
>> /feature.getType().getProperties(true)/, the methods associated to 
>> the /PropertyType/ give strange results...
>> If i do /getName()/ i would except to get the name of the property 
>> (like "the_geom"), and i obtain the property class name instead...
>>
>> I've seen there were some code changes, switching to GenericName for 
>> geotk DefaultPropertyType... maybe some side-effect was introduced 
>> there..
>>
>> Can you have a look?
>>
>> Thanks
>> Emmanuel
>>
>> Le 26/06/2015 22:54, Emmanuel Blondel a écrit :
>>> Thanks Martin,
>>>
>>> This is indeed what i decided to do: I've declared Apache SIS 
>>> 0.6-jdk7-SNAPSHOT, with the sis-metadata, and fixed some codes 
>>> related to this module.
>>>
>>> However, i'm still completely stuck with the initial error i've 
>>> reported.
>>> I looked into the maven deps resolved, and cxf-common-utilities 
>>> strangely is no there. I've tried to add cxf-core, but it didn't 
>>> solve the issue.
>>>
>>> I will continue investigating this...
>>>
>>> Le 26/06/2015 13:05, Martin Desruisseaux a écrit :
>>>> Hello Emmanuel
>>>>
>>>> Right, we modified the numbering scheme in the pom.xml for closer 
>>>> conformance to the most usual practice. Also "geotk-metadata" moved 
>>>> to Apache "sis-metadata". The later has been released 5 months ago 
>>>> as SIS 0.5, which is a stable release. The SIS 0.6 stable release 
>>>> is targeted for next month, but should have no significant change 
>>>> on the metadata side. The goal for the Apache SIS project is to be 
>>>> very stable.
>>>>
>>>> There is still a few things in the former "geotk-metadata" which 
>>>> are not yet migrated to SIS, mostly some pre-defined constants and 
>>>> a database backend. Since the former "geotk-metadata" module became 
>>>> close to empty after the port to Apache SIS, it has been merged 
>>>> with "geotk-utility". So a dependency to "geotk-utility" should 
>>>> give you (through transitive dependencies) "sis-metadata" plus the 
>>>> few additional things not yet migrated to SIS. But I would 
>>>> recommend to depend only on Apache SIS if you do not need the 
>>>> additional Geotk classes.
>>>>
>>>> The "geotk-referencing" module would probably be merged to 
>>>> "geotk-utility" in the same way when it will become close to empty 
>>>> after the port to SIS (which is in progress).
>>>>
>>>> For the exception that you reported, the stack trace suggests an 
>>>> issue with the classpath. It gives the impression that the SAX 
>>>> implementation may not be the same as it was used to be. They were 
>>>> a recent change in the dependencies declared in the pom.xml of 
>>>> "geotk-jaxp-core" module, where the "cxf-core" dependency has been 
>>>> replaced by "cxf-common-utilities" since we though that the module 
>>>> didn't need the weight of the full "cxf-core". I don't know if this 
>>>> is related, but maybe it is worth to test if re-introducing the 
>>>> "cfx-core" dependency in your project make a difference?
>>>>
>>>> https://github.com/Geomatys/geotoolkit/commit/5dac4e5238fe8e81b3bf7d83068e6a08b457393d
>>>>
>>>> About the stable release, we are close to finish Well Known Text 
>>>> (WKT 2) implementation in Apache SIS. I'm doing some tests and 
>>>> consolidation, then we will propose an Apache SIS 0.6 release in 
>>>> the next few weeks. A Geotk milestone would follow. I don't think 
>>>> that it would be "Geotk 4.0" yet (it would be "Geotk 4.0-M4"), 
>>>> since I think that we need to complete at least the port of 
>>>> "geotk-referencing" to SIS in order to provide a more consistent 
>>>> picture.
>>>>
>>>> Please let us know if the above help or if there is other things to 
>>>> consider.
>>>>
>>>>     Martin
>>>>
>>>>
>>>>
>>>>
>>>> Le 26/06/15 12:34, Emmanuel Blondel a écrit :
>>>>> It seems that in the latest monthes, you have been moving from 
>>>>> Geotk 4.x to Geotk 4.0-SNAPSHOT, isn't it?
>>>>> In the latter, there is not anymore the geotk-metadata module. I 
>>>>> was using that one, but it was yet exposing apachesis namespaces 
>>>>> (indeed i have started the transition to Apache SIS, but 
>>>>> indirectly through Geotoolkit, as recommended by Martin months ago).
>>>>> I assume that now with the Geotk 4.0-SNAPSHOT the metadata module 
>>>>> has been completely moved to apache sis, is it the case?
>>>>>
>>>>> If yes, could you please advice which Apache sis version/dep i 
>>>>> should use?
>>>>> afterwhat i would test further if i still have the issue with 
>>>>> JAXBFeatureTypeReader.
>>>>>
>>>>> Thanks in advance
>>>>> Emmanuel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Geotoolkit mailing list
>>>> Geotoolkit at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/geotoolkit
>>>
>>> -- 
>>> *Emmanuel Blondel*
>>> International Consultant | CEO
>>> /Geographic Information Systems in Agronomy, Environment, Fishery & 
>>> Marine Sciences/
>>> 41, Avenue du Vacayrial
>>> 81370 Saint Sulpice la Pointe, France
>>> Tel: +33 (0) 6 45 97 87 52
>>> Email: emmanuel.blondel1 at gmail.com <mailto:emmanuel.blondel1 at gmail.com>
>>
>> -- 
>> *Emmanuel Blondel*
>> International Consultant | CEO
>> /Geographic Information Systems in Agronomy, Environment, Fishery & 
>> Marine Sciences/
>> 41, Avenue du Vacayrial
>> 81370 Saint Sulpice la Pointe, France
>> Tel: +33 (0) 6 45 97 87 52
>> Email: emmanuel.blondel1 at gmail.com <mailto:emmanuel.blondel1 at gmail.com>
>
> -- 
> *Emmanuel Blondel*
> International Consultant | CEO
> /Geographic Information Systems in Agronomy, Environment, Fishery & 
> Marine Sciences/
> 41, Avenue du Vacayrial
> 81370 Saint Sulpice la Pointe, France
> Tel: +33 (0) 6 45 97 87 52
> Email: emmanuel.blondel1 at gmail.com <mailto:emmanuel.blondel1 at gmail.com>
>
>
> _______________________________________________
> Geotoolkit mailing list
> Geotoolkit at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geotoolkit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geotoolkit/attachments/20150629/6e2eb51c/attachment-0001.html>


More information about the Geotoolkit mailing list