[Qgis-developer] Fwd: Re: Cad-Input for QGIS prototype

[alain]

-------- 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>



Hi Olivier,

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, 
etc ...).

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 
QGis core.

Alain

Le 26/01/2014 03:08, Olivier Dalang a écrit :
> Dear list,
>
> Some times ago, on this list, we discussed[1] 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 
> prototype*.
>
>
> 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,
>
> Olivier
>
>
>
>
> [1]: 
> http://osgeo-org.1560.x6.nabble.com/Make-QGIS-interact-with-LibreCAD-td5048565.html 
>
> (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
> http://lists.osgeo.org/mailman/listinfo/qgis-developer



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140126/d8c518d1/attachment.html>