[QGIS-Developer] The need for intuitive complex feature edit support in QGIS 3+

Rui Cavaco rpcavaco at gmail.com
Tue Jan 9 15:48:52 PST 2018


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.haubourg at 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 <rpcavaco at 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.haubourg at 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 <rpcavaco at 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 at lists.osgeo.org
>>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180109/deb13242/attachment-0001.html>


More information about the QGIS-Developer mailing list