Re: [JPP-Devel] CTS PlugIn integration
Hi, Quite many of the open issues in the QGIS project deal in some way with the on-the-fly-reprojections and there are frequently OTFR related questions on the QGIS mailing list and in gis.stackexchange. Users have difficulties with understanding that the native CRS of the data may be different from the CRS of the project. More critical is that some processed so not work right /at all with on-the-fly-reprojected layers while some others work just fine. I would say that lets forget on-the-fly reprojections with OpenJUMP. One feature that I enjoy in OpenJUMP a lot is that I can just start OpenJUMP and read some data without a need to define the CRS of the project and CRS of the layer first. Michaël, it is possible to make funny troubles by reprojecting PostGIS layers. I think that reprojecting does not really work at least if layers are added from Add data store layer. Probably the vectors get reprojected initially and layer SRID is changed, but after first pan/zoom the intelligent caching system of OpenJUMP is re-reading vectors from PostGIS and they are in the native projection again. However, the layer SRID still shows the reprojected SRID. Perhaps coordinate transformation of data store layers should be prevented or the result should be directed to a new layer. But still the result could be a surprise for the users because due to intelligent caching user can't really know what features from the PostGIS table are included in the OpenJUMP layer. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Stefan Steiniger [mailto:sst...@geo.uzh.ch] Lähetetty: 16. joulukuuta 2014 21:53 Vastaanottaja: jump-pilot-devel@lists.sourceforge.net Aihe: Re: [JPP-Devel] CTS PlugIn integration Hi Michael, first of all, a big thanks for working on the integration. Now my two cents on how to do it. (a) first off all, in QGIS there is an project(?) option/checkbox to enable on the fly transformation (disabled by default). Hence, if there is no proj file, then I think there is no transformation done. Maybe we should do it the same: the user needs to enable on the fly projection for a project. Otherwise its just loaded. If I understand correctly, or at least I saw something like that, in QGIS: the datasource for some layers, e.g. CSV, is read again each time the layer is made visible (or refreshed). This means also, that data are read and projected each time. I don't remember, however, if one can edit and save back such transformed (CSV) layers. (b) editing: I wonder if it may be best to not allow editing of a layer that got projected. We could implement an (invisible) layer flag, e.g. transformed, like we have for visible, selectable and editable and an EnableCheck. So, if the user wants to edit and save a projected layer, then he first needs to create a copy of the transformed layer. This way it is clear what happens. cheers, stefan Am 14.12.14 09:55, schrieb Michael Michaud: Hi, I propose to include CTSPlugIn into OpenJUMP in two steps 1) inclusion in PLUS version after I checked with Peppe the problem with undo 2) studing how CRS can be managed at the project level (see discussion after) 3) inclusion in the CORE later if a good solution for a tighter integration is found. @peppe : undo bug : can you confirm the bug with 0.1.1 version (and last OJ NB!). I did not fix undo but could not reproduce the problem, so I will need a step by step description to reproduce the problem you reported. @ andrei : small dot bug : I could see the dot you noticed under the cursor on my machine too. For me it disappears after a few seconds. The bug is not harmful and I suspect it may be quite difficult to find the root cause. I'll not invetigate further. Tighter integration of CTS in OpenJUMP. OK, Peppe and Andrei want to get what most other GIS offer to handle coordinate system. There are several approaches to do that and all have a deep impact on teh code, and even on the results of other plugins. I would like to share some thoughts : I have a project in worldwide coordinates (WGS84) and datasources (shapefiles, images, database) in local coordinates. I can see at least two places where transformation can occur 1) opening the datasource : in-memory representation of the data could be reprojected without reprojecting datasource itself pros : data is transformed only once cons : datasource and in-memory data have not the same geometry, it needs important modifications in the code. Saving back to disk implies a double conversion where original coordinates may not be preserved, even if they have not been edited 2) displaying the dataset : I think this is the way most GIS work. Data is not altered but simply projected at display time. I prefer this way
Re: [JPP-Devel] CTS PlugIn integration
Hi Peppe, I cannot reproduce either again. It was a test made on a Vector and Raster layer together, it didn't (doesn't) happen if I test it on 2 vectors. I think that the new enablecheck implementation should avoid this sort of conflict/bug. Thanks for testing again, I agree with you: opening the possibility to have a true reprojecting implementation (like Kosmo or GvSIG) implies a strong OJ code reprogramming - probably not in our (economical, time, wish...) possibilities. My opinion is to leave everything as it is and work around the CTS plugins, maybe adding the possibility to read/write proj files (AdBToolbox, an OJ clone, has this feature, I will check the code on next days) CTS has a proj parser. I don't know exacltly how to use it though. We don't have an explicit match between prj files and epsg codes. If we want to use the same CTSPlugIn, one solution could be to detect if a prj file is associated with the layer, and if it is, to deactivate the source coordinate system combobox (as we would take automatically the prj as the source coordinate system) What is your idea ? Michaël Peppe 2014-12-14 14:17 GMT+01:00 edgar.sol...@web.de mailto:edgar.sol...@web.de: On 14.12.2014 13:55, Michael Michaud wrote: Hi, I propose to include CTSPlugIn into OpenJUMP in two steps 1) inclusion in PLUS version after I checked with Peppe the problem with undo 2) studing how CRS can be managed at the project level (see discussion after) 3) inclusion in the CORE later if a good solution for a tighter integration is found. @peppe : undo bug : can you confirm the bug with 0.1.1 version (and last OJ NB!). I did not fix undo but could not reproduce the problem, so I will need a step by step description to reproduce the problem you reported. @ andrei : small dot bug : I could see the dot you noticed under the cursor on my machine too. For me it disappears after a few seconds. The bug is not harmful and I suspect it may be quite difficult to find the root cause. I'll not invetigate further. Tighter integration of CTS in OpenJUMP. OK, Peppe and Andrei want to get what most other GIS offer to handle coordinate system. There are several approaches to do that and all have a deep impact on teh code, and even on the results of other plugins. I would like to share some thoughts : I have a project in worldwide coordinates (WGS84) and datasources (shapefiles, images, database) in local coordinates. I can see at least two places where transformation can occur 1) opening the datasource : in-memory representation of the data could be reprojected without reprojecting datasource itself pros : data is transformed only once cons : datasource and in-memory data have not the same geometry, it needs important modifications in the code. Saving back to disk implies a double conversion where original coordinates may not be preserved, even if they have not been edited 2) displaying the dataset : I think this is the way most GIS work. Data is not altered but simply projected at display time. I prefer this way, but it implies transforming data after each pan/zoom. It also has deep implication in editing tools as each edition operation must be converted from project coordinate system to datasource one. Choosing one approach or the other has consequences on most processes : Intersection points computed between segments will not be the same, buffer will not be the same, and hence all geometric results may differ according to where the transformation takes place. Debate is open Michaël PS : any choice has big implication in the code, hence my willing to dissociate transformation capability as proposed by the current plugin and tight integration wished by users. totally with you there.. that would be in line with keeping OJ lite, no funny stuff behind the scenes. integrating real time reprojection of the view is very major and i don't see a non disruptive way to do that, not even taking into account the man power needed to realize that. suggesting a reprojection when loading a different projection into a SRID marked project on the other hand, should be easy to realize and suffice for most i guess. ..ede -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get
Re: [JPP-Devel] CTS PlugIn integration
Hi Michael, first of all, a big thanks for working on the integration. Now my two cents on how to do it. (a) first off all, in QGIS there is an project(?) option/checkbox to enable on the fly transformation (disabled by default). Hence, if there is no proj file, then I think there is no transformation done. Maybe we should do it the same: the user needs to enable on the fly projection for a project. Otherwise its just loaded. If I understand correctly, or at least I saw something like that, in QGIS: the datasource for some layers, e.g. CSV, is read again each time the layer is made visible (or refreshed). This means also, that data are read and projected each time. I don't remember, however, if one can edit and save back such transformed (CSV) layers. (b) editing: I wonder if it may be best to not allow editing of a layer that got projected. We could implement an (invisible) layer flag, e.g. transformed, like we have for visible, selectable and editable and an EnableCheck. So, if the user wants to edit and save a projected layer, then he first needs to create a copy of the transformed layer. This way it is clear what happens. cheers, stefan Am 14.12.14 09:55, schrieb Michael Michaud: Hi, I propose to include CTSPlugIn into OpenJUMP in two steps 1) inclusion in PLUS version after I checked with Peppe the problem with undo 2) studing how CRS can be managed at the project level (see discussion after) 3) inclusion in the CORE later if a good solution for a tighter integration is found. @peppe : undo bug : can you confirm the bug with 0.1.1 version (and last OJ NB!). I did not fix undo but could not reproduce the problem, so I will need a step by step description to reproduce the problem you reported. @ andrei : small dot bug : I could see the dot you noticed under the cursor on my machine too. For me it disappears after a few seconds. The bug is not harmful and I suspect it may be quite difficult to find the root cause. I'll not invetigate further. Tighter integration of CTS in OpenJUMP. OK, Peppe and Andrei want to get what most other GIS offer to handle coordinate system. There are several approaches to do that and all have a deep impact on teh code, and even on the results of other plugins. I would like to share some thoughts : I have a project in worldwide coordinates (WGS84) and datasources (shapefiles, images, database) in local coordinates. I can see at least two places where transformation can occur 1) opening the datasource : in-memory representation of the data could be reprojected without reprojecting datasource itself pros : data is transformed only once cons : datasource and in-memory data have not the same geometry, it needs important modifications in the code. Saving back to disk implies a double conversion where original coordinates may not be preserved, even if they have not been edited 2) displaying the dataset : I think this is the way most GIS work. Data is not altered but simply projected at display time. I prefer this way, but it implies transforming data after each pan/zoom. It also has deep implication in editing tools as each edition operation must be converted from project coordinate system to datasource one. Choosing one approach or the other has consequences on most processes : Intersection points computed between segments will not be the same, buffer will not be the same, and hence all geometric results may differ according to where the transformation takes place. Debate is open Michaël PS : any choice has big implication in the code, hence my willing to dissociate transformation capability as proposed by the current plugin and tight integration wished by users. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Jump-pilot-devel
Re: [JPP-Devel] CTS PlugIn integration
Hi Michael, I cannot reproduce either again. It was a test made on a Vector and Raster layer together, it didn't (doesn't) happen if I test it on 2 vectors. I think that the new enablecheck implementation should avoid this sort of conflict/bug. I agree with you: opening the possibility to have a true reprojecting implementation (like Kosmo or GvSIG) implies a strong OJ code reprogramming - probably not in our (economical, time, wish...) possibilities. My opinion is to leave everything as it is and work around the CTS plugins, maybe adding the possibility to read/write proj files (AdBToolbox, an OJ clone, has this feature, I will check the code on next days) Peppe 2014-12-14 14:17 GMT+01:00 edgar.sol...@web.de: On 14.12.2014 13:55, Michael Michaud wrote: Hi, I propose to include CTSPlugIn into OpenJUMP in two steps 1) inclusion in PLUS version after I checked with Peppe the problem with undo 2) studing how CRS can be managed at the project level (see discussion after) 3) inclusion in the CORE later if a good solution for a tighter integration is found. @peppe : undo bug : can you confirm the bug with 0.1.1 version (and last OJ NB!). I did not fix undo but could not reproduce the problem, so I will need a step by step description to reproduce the problem you reported. @ andrei : small dot bug : I could see the dot you noticed under the cursor on my machine too. For me it disappears after a few seconds. The bug is not harmful and I suspect it may be quite difficult to find the root cause. I'll not invetigate further. Tighter integration of CTS in OpenJUMP. OK, Peppe and Andrei want to get what most other GIS offer to handle coordinate system. There are several approaches to do that and all have a deep impact on teh code, and even on the results of other plugins. I would like to share some thoughts : I have a project in worldwide coordinates (WGS84) and datasources (shapefiles, images, database) in local coordinates. I can see at least two places where transformation can occur 1) opening the datasource : in-memory representation of the data could be reprojected without reprojecting datasource itself pros : data is transformed only once cons : datasource and in-memory data have not the same geometry, it needs important modifications in the code. Saving back to disk implies a double conversion where original coordinates may not be preserved, even if they have not been edited 2) displaying the dataset : I think this is the way most GIS work. Data is not altered but simply projected at display time. I prefer this way, but it implies transforming data after each pan/zoom. It also has deep implication in editing tools as each edition operation must be converted from project coordinate system to datasource one. Choosing one approach or the other has consequences on most processes : Intersection points computed between segments will not be the same, buffer will not be the same, and hence all geometric results may differ according to where the transformation takes place. Debate is open Michaël PS : any choice has big implication in the code, hence my willing to dissociate transformation capability as proposed by the current plugin and tight integration wished by users. totally with you there.. that would be in line with keeping OJ lite, no funny stuff behind the scenes. integrating real time reprojection of the view is very major and i don't see a non disruptive way to do that, not even taking into account the man power needed to realize that. suggesting a reprojection when loading a different projection into a SRID marked project on the other hand, should be easy to realize and suffice for most i guess. ..ede -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE
Re: [JPP-Devel] CTS PlugIn integration
On 14.12.2014 13:55, Michael Michaud wrote: Hi, I propose to include CTSPlugIn into OpenJUMP in two steps 1) inclusion in PLUS version after I checked with Peppe the problem with undo 2) studing how CRS can be managed at the project level (see discussion after) 3) inclusion in the CORE later if a good solution for a tighter integration is found. @peppe : undo bug : can you confirm the bug with 0.1.1 version (and last OJ NB!). I did not fix undo but could not reproduce the problem, so I will need a step by step description to reproduce the problem you reported. @ andrei : small dot bug : I could see the dot you noticed under the cursor on my machine too. For me it disappears after a few seconds. The bug is not harmful and I suspect it may be quite difficult to find the root cause. I'll not invetigate further. Tighter integration of CTS in OpenJUMP. OK, Peppe and Andrei want to get what most other GIS offer to handle coordinate system. There are several approaches to do that and all have a deep impact on teh code, and even on the results of other plugins. I would like to share some thoughts : I have a project in worldwide coordinates (WGS84) and datasources (shapefiles, images, database) in local coordinates. I can see at least two places where transformation can occur 1) opening the datasource : in-memory representation of the data could be reprojected without reprojecting datasource itself pros : data is transformed only once cons : datasource and in-memory data have not the same geometry, it needs important modifications in the code. Saving back to disk implies a double conversion where original coordinates may not be preserved, even if they have not been edited 2) displaying the dataset : I think this is the way most GIS work. Data is not altered but simply projected at display time. I prefer this way, but it implies transforming data after each pan/zoom. It also has deep implication in editing tools as each edition operation must be converted from project coordinate system to datasource one. Choosing one approach or the other has consequences on most processes : Intersection points computed between segments will not be the same, buffer will not be the same, and hence all geometric results may differ according to where the transformation takes place. Debate is open Michaël PS : any choice has big implication in the code, hence my willing to dissociate transformation capability as proposed by the current plugin and tight integration wished by users. totally with you there.. that would be in line with keeping OJ lite, no funny stuff behind the scenes. integrating real time reprojection of the view is very major and i don't see a non disruptive way to do that, not even taking into account the man power needed to realize that. suggesting a reprojection when loading a different projection into a SRID marked project on the other hand, should be easy to realize and suffice for most i guess. ..ede -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
