>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

Reply via email to