Of coarse we already have the good Michael"s plugin that allows reprojection of layers( lpoint f)
Inviato con AquaMail per Android http://www.aqua-mail.com LoopThis thread needs a larger explanation. I try to simplify it. other GIS like Kosmo or GVSig implemented Coordinate system framework following these steps: a) first step they add a projection object to the task (usually as EPSG or ESRI code). In Kosmo user has to set that. QGIS also allows to set Task projection loading that from the first loadedf file (with SRID). b) QGIS define the Unit of the task from SRID ( ex. 4326>degree, 32632>metre) while GvSig And Kosmo require to set it manually. c) a projection object is set to each loaded layer. This is done reading layer metadata or manually d) if the task and the layer projection object are different a transformation should be set. Those software use ( for vector) proj4 libraries. In this step Qgis and newer gvsig allows on fly reprojection. e) this transformation is taken into account only by layer renderes on the workbench. Which changes geometry before drawing it. This transformation is saved into project file and taken into account whenever the project file is loaded. f) Note that Kosmo (and probably Gvsig) doesn't allow any spatial operation on reprojected layers. The only way to modify them is to save them reprojected. Recently I did few modifications on shape file reading in order to expand capability to set layer SRId when reading file. Layer properties plugins already have this capability for both raster and vector ( included geotif*). Together with database and wfs capability to record layer srid we probably get almost point C of my list. My idea is to work on point A and B, integrating parts if my measure plugin in to OJ core in order to have measurements\zoom when task projection is geographic or possibility that oj display meter or feet unit on measurements \ scale bar. The other points can be faced in the future, including in fly reprojection. My project: 1) Oj already as a srid registry embedded that I added when I defined srid detection capability from auxiliary files. It is a simple list of projection, a series of lines with only srid number and a proj. description ( ex <32632>;<WGS 84 UTM zone 32>), build using proj4 registries and excel. I could expand each line with unit ( ex <32632>;<WGS 84 UTM zone 32>;<metre>) 2) expand Task class with srid code and unit. User can define manually . 3) modify measure /zoom plugins according units, meter, foot, degree ( in this last case I would limit only to wgs84 ) using classes fro my measure plugin. Peppe * Inviato con AquaMail per Android http://www.aqua-mail.com Il 03 agosto 2016 12:32:48 edgar.sol...@web.de ha scritto: > hey Peppe, > > On 03.08.2016 11:11, Giuseppe Aruta wrote: >> Hi all, >> The title explains what is my idea. In a possible future we can extend OJ >> projection capabilities. And the 1st step I would explore is to add SRID >> code to a task (to centralize possible transformations) > > can you elaborate? > >>and unit of measurements (retriving from SRID, which will affect other >>plugins/tools like measure tools, measure area/length, display scales etc, >>especially for Geographic coordinate systems). > > same here. > >> I gave a look at Task class , should I implement (srid and unit) as >> properties into the associate xml file? Does it breaks compatibility? > > ..ede > > ------------------------------------------------------------------------------ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
