<div dir="ltr"><div><div><div><div>Hi Régis.<br><br></div>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.<br><br></div>Don't you think that something is missing in our graphical user interfaces to help data creators/editors/maintainers deal with such complexity?<br><br></div>Regards,<br><br></div>Rui<br></div><br><div class="gmail_quote"><div dir="ltr">Régis Haubourg <<a href="mailto:regis.haubourg@gmail.com">regis.haubourg@gmail.com</a>> escreveu no dia terça, 9/01/2018 às 15:13:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Rui, I would formulate that differently.<br></div>I have been working with INSPIRE datasets tooand a bit involved in some hydrography model workgroups. <br><br>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.<br> 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). <br>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. <br></div>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. <br></div><div><br></div><div>Regards, <br></div><div>régis<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-09 15:39 GMT+01:00 Rui Cavaco <span dir="ltr"><<a href="mailto:rpcavaco@gmail.com" target="_blank">rpcavaco@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Thanks for your response Régis.<br><br></div>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.<br></div><div><br></div>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.</div><div><br></div><div>Thanks for your suggestion. I should directly contact the GMLAS project team.</div><div><br></div><div><br></div>Best regards<span class="m_3536470186598295127HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_3536470186598295127HOEnZb"><font color="#888888">Rui Cavaco<br></font></span></div><div class="m_3536470186598295127HOEnZb"><div class="m_3536470186598295127h5"><br><div class="gmail_quote"><div dir="ltr">Régis Haubourg <<a href="mailto:regis.haubourg@gmail.com" target="_blank">regis.haubourg@gmail.com</a>> escreveu no dia terça, 9/01/2018 às 13:46:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Rui,<br></div>did you have a look at this project ? <a href="https://github.com/BRGM/gml_application_schema_toolbox" target="_blank">https://github.com/BRGM/gml_application_schema_toolbox</a> <br><br></div>I think you purchase the very same goal, a common approach seems a good idea !<br></div><div>Regards, <br></div>Régis<br></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">2018-01-09 1:17 GMT+01:00 Rui Cavaco <span dir="ltr"><<a href="mailto:rpcavaco@gmail.com" target="_blank">rpcavaco@gmail.com</a>></span>:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello list.<br><br>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. <br><br>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. <br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>I would like to join efforts with others sharing this vision in order to help make it happen in future releases of QGIS.<span class="m_3536470186598295127m_301205210618687155m_-1815829001839271683HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_3536470186598295127m_301205210618687155m_-1815829001839271683HOEnZb"><font color="#888888">Rui Cavaco<br></font></span></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div>