[Qgis-developer] Fwd: Re: Cad-Input for QGIS prototype
al.bertho at free.fr
Sun Jan 26 12:13:34 PST 2014
-------- Message original --------
Sujet: Re: [Qgis-developer] Cad-Input for QGIS prototype
Date : Sun, 26 Jan 2014 21:05:07 +0100
De : alain <al.bertho at free.fr>
Pour : Olivier Dalang <olivier.dalang at gmail.com>
There is a new category of GIS users: drone's users. There is already
the "Video UAV Tracker" for Qgis.
For myself, I use underwater drones (Autonomous Underwater Vehicle or
Unmaned Underwater Vehicle) to collect environment data. We need
softwares to prepare AUV missions, supervise these missions, and analyze
data collected during these missions.
When preparing a mission, we have to gather many data (nautical charts,
seabed sonar raster mozaics, etc...) in a single view, what Qgis does
really well (except for S57 charts). Using all these data, the user need
to plan the AUV itinerary, which can consists of waypoints, tracks,
polygons to survey. Each of these shapes will receive attributes (for
AUV, speed, depth or bottom altitude to follow, payloads to activate,
The user also need functions, like creating a group of parallel lines
oriented along some heading and spaced by a sonar range, all these lines
clipped by a polygon. These actions have to be done just using the mouse
(not by creating / naming / loading a shapefile at each step of the
process) and the keyboard to input coordinates, with transforming
DDD°MM'SSSS'' to DDD°MM.MMMM' or DDD.DDDDDD facilities for example, etc.
So, to build this itinerary, we need CAD-like input, and there's almost
nothing in Qgis really user friendly. Within my colleagues, every one
knows Qgis, but won't even try to use it for this lack. So, we use
expansive softwares, and Qgis is sometimes the swiss knife to transform
data from one software to another.
For other kind of drones, the problem is the same, with different
constraints. UAV may be very close to AUV (6 degrees of freedom), and
terrestrial robots may be more difficult to handle, because they may
have to extract the robot path from the map, but with the support of
CAD-like functions anyway.
Well, I'm not telling that Qgis has to be able to prepare missions for
every robot. But think of all the software developers who won't write a
qgis plugin for a robot, because they don't have builtin CAD-like
functions, and will choose another (proprietary) software that does the
job, but certainly won't offer Qgis skills for managing geographic data,
which is really the need for many types of robot. And I also think about
the thousands students around the world working on robot projects for
fun, who are really inovative, and may adopt QGis easily if they find
CAD-like input functions to build robot mission and then write a plugin
that fits their need to interface the robot.
About Archicad like input, I think it's a good approach.
A python plugin may be a good way to show CAD-like input has to be in
Le 26/01/2014 03:08, Olivier Dalang a écrit :
> Dear list,
> Some times ago, on this list, we discussed about real CAD-like
> input for QGIS, and since I do myself long for such a feature very
> much, I'd like to reopen that discussion by *proposing a python
> I know there are already a few plugins aiming in that direction
> (CadTools, ImprovedPolygonCapturing, NumericalInput and a few other).
> They provide the functionality, but not the ease of use you can find
> in CAD packages.
> One key aspect is that they are all specific tools, and do not work
> with other tools directly.
> The prototype is inspired from Archicad's input method which allows to
> combine numeric input with mouse input in a very efficient and
> flexible manner, to get the best of both.
> It is currently very raw and not well tested at all... It also relies
> on a lot of dirty hacks, since the python API is not well suited for
> this type of plugins (have a look at the README on the github page for
> more details).
> *DEMO (video) : https://vimeo.com/85052231*
> *GITHUB (readme, download...) : https://github.com/olivierdalang/CadInput*
> Please, tell me what you think :
> 1) Concept
> - Does this kind of input seem interesting to you ?
> - How does it fit in a GIS-environment ? Since it comes from a CAD
> environment, maybe it's more suited to designing than digitizing.
> 2) API/Core modifications (read
> https://github.com/olivierdalang/CadInput#technical-notes )
> - How do you see the suggested improvements ? Are they feasible ?
> - Does developing this as a python plugin make sense, or does it have
> to be in the core from the start ? (I'm not familiar with core developing)
> 3) Collaboration...
> - Is anyone of you currently working on the same topic ?
> - Would anyone have some time/interest in collaborating on this feature ?
> 4) Other ideas are welcome !
> Thanks for your attention,
> (To those from this discussion I cc'ed, I though you may be
> interested, I hope you don't mind)
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer