>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