Hi Régis. I want to make clear that my concern is the world of complex features and not GML by itself. I fully agree with you that complex features are best handled in a relational database.
Don't you think that something is missing in our graphical user interfaces to help data creators/editors/maintainers deal with such complexity? Regards, Rui Régis Haubourg <regis.haubo...@gmail.com> escreveu no dia terça, 9/01/2018 às 15:13: > Rui, I would formulate that differently. > I have been working with INSPIRE datasets tooand a bit involved in some > hydrography model workgroups. > > IMO, gml is nice because it allows to fully respect the UML design and > offer theoretical interoperability. Seems become darker when trying to use > it for real interoperability and everyday's use. > It is not meant to be a physical implementation for editing. It is > extremely hard to work with, with because of cascaded schema dependencies, > XML heaviness, lack of index, very wide possibilities of spatial object > modeling (so much ways to describe a simple box is crazy). > So to me, the GML is a exchange format, and should be implemented in a > transactional DB for editing , or simply for fast reading. That's why BRGM > approach relying on a spatial DB for real use sounds a goopd strategy to > me. > A bit like UML model of database can be used directly and needs to > implemented in a physical model in a relational database for real work. > > Regards, > régis > > > 2018-01-09 15:39 GMT+01:00 Rui Cavaco <rpcav...@gmail.com>: > >> Thanks for your response Régis. >> >> Yes, I read the documentation for that project. I think that's a good, >> but small, starting point. Anyway the docs mention that "the aim is to >> develop tools to manipulate Complex Features streams in a GIS desktop >> application.". So they might be seeking for something bigger. >> >> It seems that there are now some solutions, including that extension you >> mentioned, to consume complex data. But we see little, or none, efforts >> on how to produce such data. I think current user interfaces are not >> adapted to the complex feature universe. >> >> Thanks for your suggestion. I should directly contact the GMLAS project >> team. >> >> >> Best regards >> >> Rui Cavaco >> >> Régis Haubourg <regis.haubo...@gmail.com> escreveu no dia terça, >> 9/01/2018 às 13:46: >> >>> Hi Rui, >>> did you have a look at this project ? >>> https://github.com/BRGM/gml_application_schema_toolbox >>> >>> I think you purchase the very same goal, a common approach seems a good >>> idea ! >>> Regards, >>> Régis >>> >>> 2018-01-09 1:17 GMT+01:00 Rui Cavaco <rpcav...@gmail.com>: >>> >>>> Hello list. >>>> >>>> My name is Rui Cavaco, a supporter for OSGeo Portugal, and I see the >>>> need for some future major changes in desktop GIS user interfaces in order >>>> to facilitate complex features editing and querying. >>>> >>>> GML and INSPIRE are about complex features but so are fiber optic >>>> networks. Complex features could be also very productive in simpler cases >>>> like the management of city road signs and indications and other >>>> municipality themes. >>>> In order to properly support complex features I think we need to go >>>> further than the simple and old three-part GUI comprising TOC, map and >>>> attribute table. For example, attribute and form views must have "drill >>>> down" capabilities. As for the TOC, subdivding layers, as the GMLAS >>>> extension does, is not enough. Something like tree-view windows showing >>>> object hierarchies and complex objects' internal contents must exist. This >>>> is the exact same as schematics / synoptic views provided by specialized >>>> "closed source" GIS tools provided for telecom and other utilities >>>> management. Also I think the TOC should be very interactive and adaptive, >>>> in order to make possible to expose the intrincacies of sublayers without >>>> cluttering the whole layer tree with details uneeded for the current user >>>> context. >>>> >>>> Me and others discussing this subject in OSGeo-PT chat, we are >>>> convinced that without a largely available and intuitive editing support >>>> for complex features INSPIRE will soon be (some say already is) dead, >>>> despite all the the EU legal obligations. >>>> >>>> I suppose this is not a job for a single developer or a small team. I >>>> imagine this might require some profound changes in QGIS. I don't think >>>> that all these GUI changes mentioned could be "compacted" in just an >>>> extension. >>>> >>>> Funding for this effort could be raised from INSPIRE-interested EU >>>> organizations and member state government agencies. Also telecom companies >>>> and other utilities managers can be interested. Dedicated "closed source" >>>> GIS solutions for utilities are so absurdly expensive that this can open an >>>> opportunity window for Open Source based solutions. >>>> >>>> I would like to join efforts with others sharing this vision in order >>>> to help make it happen in future releases of QGIS. >>>> >>>> Rui Cavaco >>>> >>>> _______________________________________________ >>>> QGIS-Developer mailing list >>>> QGIS-Developer@lists.osgeo.org >>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> >>> >>> >
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer