Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines?
for the equivalent operation. I also hope that the menus would not changed very often. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Stefan Steiniger [mailto:sst...@geo.uzh.ch] Lähetetty: 23. tammikuuta 2012 1:07 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines? Hi Michael and others, Michael, I am not blaming you and I know that you are careful with theses things,... And yes, I know there was no feedback to Noder and Union plugin. Because, I think, it was fine. However, for the renaming a while ago.. I was travelling and did not use OJ much since. Though, the original naming was partly from me - and that maybe why I am now more active on that too. And with respect to your note on that its very short before a major release: Yes, its exactly why I am going trough it - and because I have not seen descriptions of the changes earlier for any of the in-between releases after 1.4.1 and started to look for Transfer attributes and the polygon intersection functions in my recent work and when I was trying to update documentation (But of course, maybe I did not read all the change/release notes). However, to come to the core points: (i) Overlay Polygon Layers. I thought about merge too, but you are right - its not just putting them together. Though the term Overlay is not descriptive at the end, but your argumentation w.r.t. text book definition of overlay is correct. Not sure, maybe we leave it then this way. (ii) Spatial Join - Transfer Attributes to Layer as you noticed, its DBMS speak. I really can't see why we should adopt it, because the words Spatial Join indicates a geometry operation to me. At least we should say Spatial Join of Attributes or so. (iii) Spatial Join with Aggregation - Transfer and Aggregate Attributes to Layer good comment by you on the aggregation, so I changed my proposal (vi) Polygon Intersection (one layer): I am going to add that function back - but to the edit geometry submenu, as this seems to be the place to make ops within a layer that are related to creating new datasets (well.. holds also for buffer, but...). So - for everyone who reads until here: please can I ask for the opinion on namening/re-naming back to earlier changes? stefan Am 22.01.12 15:00, schrieb Michaël Michaud: Hi Stefan, GIS function classification is really a puzzle, and it is quite difficult to make everybody happy, but as I committed most of the changes you're talking about, I'll try to explain, then, we can do any change you guys, want to do. 1 - Announcement, votes and rules are necessary... but can only apply when there is some activity : I really tried to get feedback at the time of the changes you've mentionned, (as far as I can remember 1 or 2 persons agreed and no one disagreed). 2 - Menu organisation I'm not completely satisfied with current organisation, but I think it is better now than one year ago. - We find most usual GIS Analysis tools in ToolsAnalyis (which is good) except some in ToolsEdit Geometry (which, in my opinion, is not so good) - We removed One Layer/Two Layers submenu. I think this separation made sense, but it was not very user-friendly as the user had to answer one more question before he could find the menu item he was looking for - I have not hesitated much before I changed Run Database query to file menu, because all input/output are in File menu now, including database access, and in my opinion, searching Run Query tool in Layer menu was just a bad habit. Maybe I did not communicate enough about this change though ;o( 3 - Menu item names. I've to be more careful on this subject as my english is not so good However, as I understand gis terms, overlay applies quite well to Overlay Polygon Layers... menu item (a bit less to Overlay...) Some definitions of Overlay : Overlay: A formal geometric intersection between two or more layers of spatially referenced data. A layer produced by an overlay will contain both the spatial data and the attribute data from the input layers. Polygon overlay : A process that merges spatially coincident polygons from two coverages, and their attributes, to create a third coverage, that contains new polygons and describes new relationships ... Overlay is the core part of GIS analysis operation. It combines several spatial features to generate new spatial elements. AFAIK, this is what Overlay Polygon Layers does, isn't it ? Currently, Overlay... menu item output is limited to intersections So for this one, Intersection would also apply Ideally, I would like a single Overlay menu item which would process all features (not only Polygons), and not limited to intersections (a mix of both plugins if you followed me), but this is out of scope now. For now, I agree Intersection would also fit what current
Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines?
Hi, Do I remember right or was there some academic teacher with the discussion back then? And the reason for changing some naming and grouping was aiming to better match with some OGC document? I feel it is confusing to have slightly different names for about similar but not exactly same operations in ESRI world, OGC definitions etc. Union/merge/dissolve is one example that comes to my mind. It may be impossible to find an uniform names for everything. Some little example images about source layers before operation and after that would be nice to have available when selecting the tools and why not a lexicon telling what terms other popular softwares are using for the equivalent operation. I also hope that the menus would not changed very often. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Stefan Steiniger [mailto:sst...@geo.uzh.ch] Lähetetty: 23. tammikuuta 2012 1:07 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines? Hi Michael and others, Michael, I am not blaming you and I know that you are careful with theses things,... And yes, I know there was no feedback to Noder and Union plugin. Because, I think, it was fine. However, for the renaming a while ago.. I was travelling and did not use OJ much since. Though, the original naming was partly from me - and that maybe why I am now more active on that too. And with respect to your note on that its very short before a major release: Yes, its exactly why I am going trough it - and because I have not seen descriptions of the changes earlier for any of the in-between releases after 1.4.1 and started to look for Transfer attributes and the polygon intersection functions in my recent work and when I was trying to update documentation (But of course, maybe I did not read all the change/release notes). However, to come to the core points: (i) Overlay Polygon Layers. I thought about merge too, but you are right - its not just putting them together. Though the term Overlay is not descriptive at the end, but your argumentation w.r.t. text book definition of overlay is correct. Not sure, maybe we leave it then this way. (ii) Spatial Join - Transfer Attributes to Layer as you noticed, its DBMS speak. I really can't see why we should adopt it, because the words Spatial Join indicates a geometry operation to me. At least we should say Spatial Join of Attributes or so. (iii) Spatial Join with Aggregation - Transfer and Aggregate Attributes to Layer good comment by you on the aggregation, so I changed my proposal (vi) Polygon Intersection (one layer): I am going to add that function back - but to the edit geometry submenu, as this seems to be the place to make ops within a layer that are related to creating new datasets (well.. holds also for buffer, but...). So - for everyone who reads until here: please can I ask for the opinion on namening/re-naming back to earlier changes? stefan Am 22.01.12 15:00, schrieb Michaël Michaud: Hi Stefan, GIS function classification is really a puzzle, and it is quite difficult to make everybody happy, but as I committed most of the changes you're talking about, I'll try to explain, then, we can do any change you guys, want to do. 1 - Announcement, votes and rules are necessary... but can only apply when there is some activity : I really tried to get feedback at the time of the changes you've mentionned, (as far as I can remember 1 or 2 persons agreed and no one disagreed). 2 - Menu organisation I'm not completely satisfied with current organisation, but I think it is better now than one year ago. - We find most usual GIS Analysis tools in ToolsAnalyis (which is good) except some in ToolsEdit Geometry (which, in my opinion, is not so good) - We removed One Layer/Two Layers submenu. I think this separation made sense, but it was not very user-friendly as the user had to answer one more question before he could find the menu item he was looking for - I have not hesitated much before I changed Run Database query to file menu, because all input/output are in File menu now, including database access, and in my opinion, searching Run Query tool in Layer menu was just a bad habit. Maybe I did not communicate enough about this change though ;o( 3 - Menu item names. I've to be more careful on this subject as my english is not so good However, as I understand gis terms, overlay applies quite well to Overlay Polygon Layers... menu item (a bit less to Overlay...) Some definitions of Overlay : Overlay: A formal geometric intersection between two or more layers of spatially referenced data. A layer produced by an overlay will contain both the spatial data and the attribute data from the input layers. Polygon
Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines?
On 23.01.2012 00:06, Stefan Steiniger wrote: So - for everyone who reads until here: please can I ask for the opinion on namening/re-naming back to earlier changes? as a no gis person i'll pass on this.. you guys better suited for that issue.. ede -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines?
Hi, at 2011.05.16 we had a discussion about changing menues (see below). My opinion again is to use names from OGC. http://www.opengeospatial.org/standards/sfa Please do not change every OJ version the menues! Because it is hard work for the users to find them and it is hard to update a tutorial. Regards Uwe (The academic teacher) :-) old mail: Hi Michaël, thank you for your answer The problem with one/two layer is, that the Geometry Functions works with one and with two layers. So maybe it is better to avoid splitting in one/two layer. Maybe you have the old OpenJUMP version 1.2F. There you find the whole Analysis functions under ToolsAnalysis... But you are right. This is my opinion. Please ask the other users what they think about this. Thank you for your help. Regards Uwe Am 16.05.2011 08:27, schrieb Michaël Michaud: Hi, I'll post to the list again when I'll have the whole picture (submenus with new items and submenus with removed items) When you propose to put some items to the Analysis submenu, in your opinion, should they be directly under Analysis ? under AnalysisOneLayer ? Do you keep OneLayer/TwoLayer submenus ? Thanks, Michaël Le 16/05/2011 08:18, Michaël Michaud a écrit : Hi Uwe, I'm sorry, I was quite sure I sent an answer, but I should have delete my mail before I sent it. I think you make a good point by refering to OGC standard. I'm also not completely satisfied with the current tools menu. What I would like is - to have a clear vision of the whole menu (I think that the changes you propose may have other consequences on non-ogc features, and that some submenus may loose their legitimity after that change) - I'd like to have some feedback from other power users, because I think that many users have teir own idea about where tools should be and we already moves some tools. I will post your propositions again to the list Thanks, Michaël Le 16/05/2011 07:57, Uwe Dalluege a écrit : Good morning Michaël, last week I posted following mail to the JPP-Devel list (I hope so) I am not shure whether this mail arrived the mailing list. What do you you think about my suggestion? Do you think that it is possible and usefull to change the menues? Greeting from Hamburg Uwe Hi, it is a little tricky to find the spatial analysis functions in OpenJUMP. In the OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture http://www.opengeospatial.org/standards/sfa you find at page 17 (6.1.2.4) Methods that support spatial analysis there you find for example Buffer, Intersection and ConvexHull. Is it possible to move a) ToolsGenerateBuffer b) ToolsGenerateConvex Hull c) ToolsGenerateConvex Hull on Layer... d) ToolsEdit GeometryGeometry Functions... to ToolsAnalysis? because in the OGC Specification you will find this functions under Analysis. Regards Uwe Mit freundlichen Gruessen Uwe Dalluege Am 23.01.2012 11:58, schrieb Rahkonen Jukka: Hi, Do I remember right or was there some academic teacher with the discussion back then? And the reason for changing some naming and grouping was aiming to better match with some OGC document? I feel it is confusing to have slightly different names for about similar but not exactly same operations in ESRI world, OGC definitions etc. Union/merge/dissolve is one example that comes to my mind. It may be impossible to find an uniform names for everything. Some little example images about source layers before operation and after that would be nice to have available when selecting the tools and why not a lexicon telling what terms other popular softwares are using for the equivalent operation. I also hope that the menus would not changed very often. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Stefan Steiniger [mailto:sst...@geo.uzh.ch] Lähetetty: 23. tammikuuta 2012 1:07 Vastaanottaja: OpenJump develop and use Aihe: Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines? Hi Michael and others, Michael, I am not blaming you and I know that you are careful with theses things,... And yes, I know there was no feedback to Noder and Union plugin. Because, I think, it was fine. However, for the renaming a while ago.. I was travelling and did not use OJ much since. Though, the original naming was partly from me - and that maybe why I am now more active on that too. And with respect to your note on that its very short before a major release: Yes, its exactly why I am going trough it - and because I have not seen descriptions of the changes earlier for any of the in-between releases after 1.4.1 and started to look for Transfer attributes and the polygon intersection functions in my recent work and when I was trying to update
[JPP-Devel] Renaming functions and moving menu positions - need for guidelines?
Hi all, now, after having sent of the other email, I tried to analyse why I am actually unhappy with what happened. It came out pretty simple: I was used to the old naming and menu positions furthermore, there was just right now an email on the user list about Where is that function gone (in this case datastore query). It highlights a couple of things, that we can summarize as don't change the User API without a clear announcement. But in detail: - if we change names, then users may not found the function anymore - if we change the menu positions of functions, then users may not found them anymore further: - names should be descriptive - names should adhere to standards (not necessarily to ArcGIS, but sometimes...) I also recognized the following: - ESRI never changed names of function as long as I remember, except maybe when they moved from 8.x to 9.x and got a complete new user interface - ESRI is using function names that are not very descriptive all the time, but they try to restrict it to one word - which describes the action, e.g. eliminate, dissolve, union, spatial join. - I actually do not aggree with some ESRI naming of functions, since the technical standards (OGC SFS) use actually different names (union vs. intersection, dissolve vs. union). But I guess the reason is that the standards are younger than ArcInfo/GIS. So, based on that I see a need for the next release notes (for 1.5.1) to 1) describe somewhere what functions have been renamed and moved (quite a bit). 2) To introduce proper naming and location rules. And related to that I think the location and naming of new functions need to be approved by at least 3 people - and not changed anymore thereafter until a major release (X.X). Any further opinions? stefan -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines?
Hi Landon, we actually have already a wiki page with some developer guide lines - written by Michael a while ago. But they are more code specific until now. stefan Am 22.01.12 12:44, schrieb Landon Blake: Stefan, You mentioned good ideas in your e-mail. It seems to me that these proposed rules would be a good start for a set OpenJUMP Developer Guideline's. I would be willing to put together a document with the guidelines, starting with only the rules in Stefan's e-mail, if others think it is a good idea. I'm not wanting to hit someone over the head with a book of rules, but I think it would be a good idea to have this guidance for programmers in one spot. Stefan wrote: And related to that I think the location and naming of new functions need to be approved by at least 3 people. It seems, at least by the amount of e-mail, that there is quite a bit or OJ development going on in recent weeks. The increased activity would seem to benefit from at least a wee bit more structure and coordination. I'd suggest these 3 people be our reformed development committee. I would suggest as members, if they were willing, Stefan, Michael, and Ede. They seem to be the most active. This is just a suggestion. :] Landon On Sun, Jan 22, 2012 at 10:48 AM, Stefan Steinigersst...@geo.uzh.ch wrote: Hi all, now, after having sent of the other email, I tried to analyse why I am actually unhappy with what happened. It came out pretty simple: I was used to the old naming and menu positions furthermore, there was just right now an email on the user list about Where is that function gone (in this case datastore query). It highlights a couple of things, that we can summarize as don't change the User API without a clear announcement. But in detail: - if we change names, then users may not found the function anymore - if we change the menu positions of functions, then users may not found them anymore further: - names should be descriptive - names should adhere to standards (not necessarily to ArcGIS, but sometimes...) I also recognized the following: - ESRI never changed names of function as long as I remember, except maybe when they moved from 8.x to 9.x and got a complete new user interface - ESRI is using function names that are not very descriptive all the time, but they try to restrict it to one word - which describes the action, e.g. eliminate, dissolve, union, spatial join. - I actually do not aggree with some ESRI naming of functions, since the technical standards (OGC SFS) use actually different names (union vs. intersection, dissolve vs. union). But I guess the reason is that the standards are younger than ArcInfo/GIS. So, based on that I see a need for the next release notes (for 1.5.1) to 1) describe somewhere what functions have been renamed and moved (quite a bit). 2) To introduce proper naming and location rules. And related to that I think the location and naming of new functions need to be approved by at least 3 people - and not changed anymore thereafter until a major release (X.X). Any further opinions? stefan -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Renaming functions and moving menu positions - need for guidelines?
Hi Michael and others, Michael, I am not blaming you and I know that you are careful with theses things,... And yes, I know there was no feedback to Noder and Union plugin. Because, I think, it was fine. However, for the renaming a while ago.. I was travelling and did not use OJ much since. Though, the original naming was partly from me - and that maybe why I am now more active on that too. And with respect to your note on that its very short before a major release: Yes, its exactly why I am going trough it - and because I have not seen descriptions of the changes earlier for any of the in-between releases after 1.4.1 and started to look for Transfer attributes and the polygon intersection functions in my recent work and when I was trying to update documentation (But of course, maybe I did not read all the change/release notes). However, to come to the core points: (i) Overlay Polygon Layers. I thought about merge too, but you are right - its not just putting them together. Though the term Overlay is not descriptive at the end, but your argumentation w.r.t. text book definition of overlay is correct. Not sure, maybe we leave it then this way. (ii) Spatial Join - Transfer Attributes to Layer as you noticed, its DBMS speak. I really can't see why we should adopt it, because the words Spatial Join indicates a geometry operation to me. At least we should say Spatial Join of Attributes or so. (iii) Spatial Join with Aggregation - Transfer and Aggregate Attributes to Layer good comment by you on the aggregation, so I changed my proposal (vi) Polygon Intersection (one layer): I am going to add that function back - but to the edit geometry submenu, as this seems to be the place to make ops within a layer that are related to creating new datasets (well.. holds also for buffer, but...). So - for everyone who reads until here: please can I ask for the opinion on namening/re-naming back to earlier changes? stefan Am 22.01.12 15:00, schrieb Michaël Michaud: Hi Stefan, GIS function classification is really a puzzle, and it is quite difficult to make everybody happy, but as I committed most of the changes you're talking about, I'll try to explain, then, we can do any change you guys, want to do. 1 - Announcement, votes and rules are necessary... but can only apply when there is some activity : I really tried to get feedback at the time of the changes you've mentionned, (as far as I can remember 1 or 2 persons agreed and no one disagreed). 2 - Menu organisation I'm not completely satisfied with current organisation, but I think it is better now than one year ago. - We find most usual GIS Analysis tools in ToolsAnalyis (which is good) except some in ToolsEdit Geometry (which, in my opinion, is not so good) - We removed One Layer/Two Layers submenu. I think this separation made sense, but it was not very user-friendly as the user had to answer one more question before he could find the menu item he was looking for - I have not hesitated much before I changed Run Database query to file menu, because all input/output are in File menu now, including database access, and in my opinion, searching Run Query tool in Layer menu was just a bad habit. Maybe I did not communicate enough about this change though ;o( 3 - Menu item names. I've to be more careful on this subject as my english is not so good However, as I understand gis terms, overlay applies quite well to Overlay Polygon Layers... menu item (a bit less to Overlay...) Some definitions of Overlay : Overlay: A formal geometric intersection between two or more layers of spatially referenced data. A layer produced by an overlay will contain both the spatial data and the attribute data from the input layers. Polygon overlay : A process that merges spatially coincident polygons from two coverages, and their attributes, to create a third coverage, that contains new polygons and describes new relationships ... Overlay is the core part of GIS analysis operation. It combines several spatial features to generate new spatial elements. AFAIK, this is what Overlay Polygon Layers does, isn't it ? Currently, Overlay... menu item output is limited to intersections So for this one, Intersection would also apply Ideally, I would like a single Overlay menu item which would process all features (not only Polygons), and not limited to intersections (a mix of both plugins if you followed me), but this is out of scope now. For now, I agree Intersection would also fit what current Overlays plugin does. I don't agree with Merge as features are not merged, but divided as they intersect each others ! About join versus transfer attribute, I agree with you that transfer attribute is more easy to understand for anyone who has not a strong dbms background. However, one of the tool do not transfer attribute but aggregate values, and the other one creates new features for each
