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 Tools>Analysis>... 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 > Analysis>OneLayer ? 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) Tools>Generate>Buffer >>> b) Tools>Generate>Convex Hull >>> c) Tools>Generate>Convex Hull on Layer... >>> d) Tools>Edit Geometry>Geometry Functions... >>> >>> to >>> >>> Tools>Analysis? >>> >>> >>> 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:[email protected]] >> 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 Tools>Analyis >> (which is good) >>> except some in Tools>Edit 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 match >>> which is exactly what a JOIN does (respectively with and without >>> a group by statement) and what is a bit different from what one >>> can expect with a name like "transfer attribute. >>> >>> That said, I'm very pleased to discuss these things with >> expert users >>> and just regret that the discussion comes one week before a major >>> release. >>> If you organize a vote to make sure we do the right >> decision, I'll be >>> pleased to vote and to accept the decision of the community, >>> but remember, I asked 2 questions about new Noder and new Union >>> plugin months ago, and I never get the 3 votes to make a decision ! >>> >>> Regards, >>> >>> Michaël >>> >>> >>> >>> >>> >>> Le 22/01/2012 19:48, Stefan Steiniger a écrit : >>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
