hi Even, thanks for the quick reply - seems to make sense and chimes with what we've found - certainly in the short term I think we can use gml:PointProperty to get us where we want to go.... The Marine S-100 model adds an association to an information type into the geometry primitive by extension - not a mechanism we're actualyl using in the Application Schema we're creating right now but conceivably it could be a sticking point for both marine users within the S-100 GML Profile and possibly other users where a profile of GML is constructuced which is then used to create multiple sub-products (not sure if INSPIRE ever went down this route tho). So... alternatives could be to allow the gml namespace to be aliased by a configuraiton optjon in gmlasconf.xml or to identify gml:[primitive] or any extension of those primitves as geometry to the identified OGRFeature - that's more structural though and would need the applciation schema driver to look at the derivation of each of the elements in the schema.... thoughts? I'll also check with the S-100 folks in charge of the S-100 PArt 10b where the profile is and see if we can come up with an agreed proposal at least....
cheers, JP On Thu, 25 Jul 2019 at 16:27, Even Rouault <[email protected]> wrote: > Jonathan, > > Identification of geometries could probably be improved in the driver (was > mostly tested / developed for Inspire data models, and in my memories of > the > ones that were tested, plain GML geometries were used). That said, if your > s100:PointPropertyType is just a plain gml:PointPropertyType, I'd suggest > to > opt for simplicity and use the GML namespace. It will make it obvious to > everybody: humans and software having to deal with it. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
