Michael, Let me know if you have suggestions on how I can improve my solution.
The Sunburned Surveyor On Thu, Apr 17, 2008 at 1:52 PM, Michaël Michaud <[EMAIL PROTECTED]> wrote: > > >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? > > > > > Yes it does. > I understand that the user will have to know what the real data unit > system is and will be able to choose what the user interface will display. > Fine. > > Michaël > > > >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 > > > > > > > > > > > ------------------------------------------------------------------------- > 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
