I will respond to Martin, Stefan, and Michael in turn. Martin wrote: "his is exactly the kind of use case the Registry was meant to support. It is a system-wide repository for non-deleteable value objects of specific categories. Your scenario for development sounds just fine to me."
Thank you for the feedback Martin. I am beginning to understand both the purpose and the utility of the Registry object. Stefan wrote: "I would actually prefer to integrate it in the core directly - as it is a needed feature." Why don't I make sure it works as a plug-in first? If I don't mess things up to badly, we can talk about integrating it into the core. :] Stefan wrote: "however, not sure if other things than distances (and areas) are of interest." The way the library is being designed will allow us to work with any type of unit system. However, I agree that the distance unit system and area unit system will be the two types of unit systems we are primarily interested in. Michael wrote: "From my point of view, the problem has two "sides" : - one side is the unit system Coordinates refer to. - the other side is the unit system you want to display..." This is a most excellent point Michael. I should have been more clear about the purpose of my library. I'm not trying to solve the first problem you mention, but the second problem. You can think of my work as an extension of I18N. I'm just trying to provide a consistent way to format numerical measurements for display in a unit system the user is accustomed to. I'm not trying to make the underlying JTS geometry library used in JTS "unit aware" or anything like that. I rather prefer to keep the underbelly of OpenJUMP "unitless", because I think it makes for a simpler system. Michael wrote: "but it is important to mention that a unit system plugin should be aware of the unit system associated used by feature geometries, if such a unit system is defined (I think it is for WMS layers)." I agree. I'm leaving this responsibility up to the programmer that implements tools that need to work with unit systems. I'm just providing a way to define a unit system and to format a mearurement for a particular unit system and Locale (language). Does this make sense? I hope that I have answered your concerns. I will make my source code available for others to review as soon as I have an alpha release working. Maybe in a couple weeks? The Sunburned Surveyor On Wed, Apr 16, 2008 at 11:51 PM, Michaël Michaud <[EMAIL PROTECTED]> wrote: > Hi, > > I'm not sure to understand how you want to implement the Unit System > plugin. From my point of view, the problem has two "sides" : > - one side is the unit system Coordinates refer to. In an ideal world, > this parameter should be included in the "Coordinate Reference System" > associated with the Geometries. I think OpenJUMP has already some stuff > to manage C.R.S. systems > - the other side is the unit system you want to display : if it is > different from the one used in the Coordinate objects, you have to do a > transformation which should be included in a general coordinate > operation tool able to change the datum, the projection or just the unit > system. > > I recognize that unit system could be managed in a more simple way in > the meantime, but it is important to mention that a unit system plugin > should be aware of the unit system associated used by feature > geometries, if such a unit system is defined (I think it is for WMS layers). > > Michaël > > Stefan Steiniger a écrit : > > > > >Hei, > > > >to me it sounds still a bit abstract (i.e. not sure what you > >implementation would all encompass in terms of classes and so on) > >but as martin agrees I have no problems with that. > > > >btw. I would actually prefer to integrate it in the core directly - as > >it is a needed feature. however, not sure if other things than distances > > (and areas) are of interest. > > > >stefan > > > >Martin Davis schrieb: > > > > > >>SS, > >> > >>This is exactly the kind of use case the Registry was meant to support. > >>It is a system-wide repository for non-deleteable value objects of > >>specific categories. Your scenario for development sounds just fine to me. > >> > >>Martin > >> > >>Sunburned Surveyor wrote: > >> > >> > >>>I remembered someone (I think Jon Aquino) mentioning that an object > >>>called a Registry could be used to access data throughout OpenJUMP. I > >>>was skimming the Javadoc for the Registry class and I think I can use > >>>it to allow plug-ins to contribute unit systems. > >>> > >>>In this scenario the unit system contribution would work something like > this: > >>> > >>>[1] The plug-in programmer would implement an extension of the > >>>standard plug-in interface built specifically to contribute unit > >>>systems. > >>> > >>>[2] In the plug-in's initialize() method the programmer would create > >>>and store an object containing some basic information about the unit > >>>system his plug-in would contribute. This would include a user > >>>friendly name for the unit system, the type of unit system, and the > >>>fully qualified name of the class that implements the UnitSystem > >>>interface. This object would be added to the registry using the > >>>classification, or key, "Unit Systems Information". (Each > >>>implementation of the UnitSystem interface would require a no-argument > >>>constructor.) > >>> > >>>[3] Other OpenJUMP plug-in programmers could ask the registry for all > >>>unit system information objects. These could be used to build a list > >>>of unit systems available to the user. When a unit system was needed, > >>>a instance could be created using the fully qualified class name in > >>>the unit system information object and the classForName method. (Thus > >>>the requirement for a no argument constructor.) > >>> > >>>Any thoughts on this approach? Its not the most elegant, but I think > >>>it will work within the constraints of our existing plug-in system > >>>without requiring any modifications to the core. > >>> > >>>The Sunburned Surveyor > >>> > >>>------------------------------------------------------------------------- > >>>This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > >>>Don't miss this year's exciting event. There's still time to save $100. > >>>Use priority code J8TL2D2. > > >>>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > >>>_______________________________________________ > >>>Jump-pilot-devel mailing list > >>>Jump-pilot-devel@lists.sourceforge.net > >>>https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >>> > >>> > >>> > >>> > > > >------------------------------------------------------------------------- > >This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > >Don't miss this year's exciting event. There's still time to save $100. > >Use priority code J8TL2D2. > > >http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > >_______________________________________________ > >Jump-pilot-devel mailing list > >Jump-pilot-devel@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
