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
