Menu
▾
▴
geobject-core — Discussing the Geobject Core specification
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(66) |
Sep
(11) |
Oct
|
Nov
(26) |
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Jagriti M. <sa...@we...> - 2015-10-08 13:02:17
|
Dear geo...@li..., Hope you are doing well today. It's just a reminder of my previous mail regarding (Would you be interested to build a website like <http://airbnb.com> airbnb.com?) Would you be interested in further discussion? simply reply us your requirement along with your contact details and we'll be in touch shortly. N.B:- It's my last follow up email to you. Warm Regards, Jagriti Mogha <mailto:sa...@we...> sa...@we... Marketing Manager Head Office: San Jose, CA 95120 ____________________________________________________________________________ ___________________________________________________________________ Disclaimer: P.S. This is an advertisement and a promotional mail strictly on the guidelines of CAN-SPAM act of 2007. We have clearly mentioned the source mail-id of this mail, also clearly mentioned the subject lines and they are in no way misleading in any form. We have found your mail address through our own efforts on the web search and not through any illegal way. If you find this mail unsolicited, please reply with " <mailto:sa...@we...> Remove" in the subject line and we will take care that you do not receive any further promotional mail. ____________________________________________________________________________ ___________________________________________________________________ From: Jagriti Mogha [ <mailto:sa...@we...> mailto:sa...@we...] Sent: 06 October 2015 12:17 To: geo...@li... Subject: Airbnb: How 2 Guys rent out a room and now owned 10 billion USD company. Hi there, Hope you are doing good. I came across your business and noticed that you are from Real Estate Industry so thought to get in touch with you. Our company has developed a clone of <http://airbnb.com/> Airbnb.com, a popular holiday rental website for home lodging. This solution is responsive and built on open source technology considering the long term business requirements. This online application be an add on to your existing online presence and can add additional income source for your business. Airbnb launched in 2008 as just a simple idea to help 2 guys rent out a room in their apartment. In just 7 years, Airbnb is now USD 10 billion company with millions of unique visitors each day. The core features that we are offering are as follows: . Property/Space listing . Map Based Search . Owner Listing Packages (Paypal integrated) . Availability Calendar, Photos, Map . Booking Management . Super Admin Panel and lot many other features Please let me know if this is something of your interest. simply reply us your requirement along with your contact details and we'll be in touch shortly. Warm Regards, Jagriti Mogha <mailto:sa...@we...> sa...@we... Marketing Manager Head Office: San Jose, CA 95120 ____________________________________________________________________________ ___________________________________________________________________ Disclaimer: P.S. This is an advertisement and a promotional mail strictly on the guidelines of CAN-SPAM act of 2007. We have clearly mentioned the source mail-id of this mail, also clearly mentioned the subject lines and they are in no way misleading in any form. We have found your mail address through our own efforts on the web search and not through any illegal way. If you find this mail unsolicited, please reply with " <mailto:sa...@we...> Remove" in the subject line and we will take care that you do not receive any further promotional mail. |
|
From: Jagriti M. <sa...@we...> - 2015-10-06 15:29:01
|
Hi there, Hope you are doing good. I came across your business and noticed that you are from Real Estate Industry so thought to get in touch with you. Our company has developed a clone of <http://airbnb.com/> Airbnb.com, a popular holiday rental website for home lodging. This solution is responsive and built on open source technology considering the long term business requirements. This online application be an add on to your existing online presence and can add additional income source for your business. Airbnb launched in 2008 as just a simple idea to help 2 guys rent out a room in their apartment. In just 7 years, Airbnb is now USD 10 billion company with millions of unique visitors each day. The core features that we are offering are as follows: . Property/Space listing . Map Based Search . Owner Listing Packages (Paypal integrated) . Availability Calendar, Photos, Map . Booking Management . Super Admin Panel and lot many other features Please let me know if this is something of your interest. simply reply us your requirement along with your contact details and we'll be in touch shortly. Warm Regards, Jagriti Mogha <mailto:sa...@we...> sa...@we... Marketing Manager Head Office: San Jose, CA 95120 ____________________________________________________________________________ ___________________________________________________________________ Disclaimer: P.S. This is an advertisement and a promotional mail strictly on the guidelines of CAN-SPAM act of 2007. We have clearly mentioned the source mail-id of this mail, also clearly mentioned the subject lines and they are in no way misleading in any form. We have found your mail address through our own efforts on the web search and not through any illegal way. If you find this mail unsolicited, please reply with " <mailto:sa...@we...> Remove" in the subject line and we will take care that you do not receive any further promotional mail. |
|
From: jesse c. <cro...@po...> - 2002-12-13 23:49:39
|
the get/setRelativeBearing methods would return/take an OrientationSource. the Unit parameter would be eliminated, as it is contained within an Orientation. so, in usage, you would call setRelativeBearing(some_BearingTrueNorth) or setRelativeBearing(some_PlanarAngle), thus freeing us from the constraint of 'units clockwise from due north' currently used in RelativeRangeBearing. Chris Dillard wrote: > How would you suggest we change RelativeRangeBearing (for example)? > > Chris D. > > -----Original Message----- > From: Jesse Crossley > Sent: Friday, December 13, 2002 3:42 PM > To: geo...@li... > Cc: Chris Dillard; Christopher Priebe > Subject: RangeBearing/RelativeRangeBearing and everything with > 'Bearing' > > should all of these have been changed to use Orientations? > if we don't change them, then we're right back in the original mess, > depending on JavaDoc to insure that users feed in correctly oriented > value using the correct units. > > RangeBearing is a GeoVector and RelativeRangeBearing is a > RelativeCoordinate, so we don't have the problem with defining an > Orientation with another Orientation. but RangeBearing and > RelativeRangeBearing (maybe others i've missed, oh, > > prolly RangeBearingAzimuth) have 'bearings' and their Orientation is > defined by the documentation. > > not that i want the extra work, mind you, but if'n we're gonna do this > right, then by gosh, we're gonna do it right. > > jdc |
|
From: Chris D. <cdi...@po...> - 2002-12-13 23:45:15
|
How would you suggest we change RelativeRangeBearing (for example)? Chris D. -----Original Message----- From: Jesse Crossley=20 Sent: Friday, December 13, 2002 3:42 PM To: geo...@li... Cc: Chris Dillard; Christopher Priebe Subject: RangeBearing/RelativeRangeBearing and everything with 'Bearing' should all of these have been changed to use Orientations? if we don't change them, then we're right back in the original mess, depending on JavaDoc to insure that users feed in correctly oriented value using the correct units. RangeBearing is a GeoVector and RelativeRangeBearing is a RelativeCoordinate, so we don't have the problem with defining an Orientation with another Orientation. but RangeBearing and RelativeRangeBearing (maybe others i've missed, oh, prolly RangeBearingAzimuth) have 'bearings' and their Orientation is defined by the documentation. not that i want the extra work, mind you, but if'n we're gonna do this right, then by gosh, we're gonna do it right. jdc |
|
From: jesse c. <cro...@po...> - 2002-12-13 23:43:21
|
should all of these have been changed to use Orientations? if we don't change them, then we're right back in the original mess, depending on JavaDoc to insure that users feed in correctly oriented value using the correct units. RangeBearing is a GeoVector and RelativeRangeBearing is a RelativeCoordinate, so we don't have the problem with defining an Orientation with another Orientation. but RangeBearing and RelativeRangeBearing (maybe others i've missed, oh, prolly RangeBearingAzimuth) have 'bearings' and their Orientation is defined by the documentation. not that i want the extra work, mind you, but if'n we're gonna do this right, then by gosh, we're gonna do it right. jdc |
|
From: jesse c. <cro...@po...> - 2002-12-13 22:21:56
|
okay, i haven't gotten any feedback, but ima gonna make the following
changes anyway:
1) removing the OrientationConverterFactory and all things that refer to it.
2) adding a getOrientationConverter method to the OrientationFactory
(instead of
having a separate OrientationConverterFactory). this follows the
pattern in CoordinateFactory.
3) changing the getCoordinateList method on CoordinateFactory to
createCoordinateList,
since that's what it does and it will then match up with
createCoordinate, createRelativeCoordinate.
no arguments? i thought not...
all for now,
jdc
|
|
From: jesse c. <cro...@po...> - 2002-12-13 01:21:18
|
i still haven't quite digested this last bit. but i undid my changes (and committed quite a bit of stuff) so at least we're all back at the same point. (well, not exactly. PLEASE review what's been added and confirm/deny that it's what you expected. some changes are purely cosmetic (file formatting, uh..., order of params in DashPattern constructor), i'm more interested in feedback on actual code changes i've made). i've got a question about OrientationConverterFactory. now, we don't have a CoordinateConverterFactory, we just have a convert method on Coordinate. we now also have convert a method on Orientation, so do we need an OrientationConverterFactory? i'm thinking 'no', but i base this opinion on parallel classes, not on any real examination of existing code. jdc <snip>stuff about patterns and styles</snip> |
|
From: Robert H. \(old\) <rha...@sa...> - 2002-12-10 06:17:54
|
First, a comment/question about the javadoc.=20
"An implementation may also implement
other line patterns not listed here by creating instances
of a <code>DashPattern</code>.</p>"
I thought, maybe incorrectly (it's the hair), that the USER of the =
implementation would be able to create new instances of DashPattern, if =
the implmentation supported user-defined DashPattern's. Custome =
LinePattern's like -> -> -> would be created by the impl creating it's =
own subsclass of LinePattern say NeatoLinePatterns with several enums =
that are only supported by the Neato impl of geobject.
Note that, if you are using two different impls of Geobject in the same =
VM your list of LinePatterns is going to be the union of the =
LinePatterns. This might be what you want. However, exposing getArray =
encourages USER's to serialize the getValue() int, but that's a bad =
thing to do from impl to impl. As defined, the extensible nature of =
Geobject means that the serialization should be in the framework (that =
is the framework has it's own fixed idea of line-patterns and it just =
tries to find the right geobject linepattern at run-time), or in =
Geobject itself. Ad hoc use of getByValue will not work from impl to =
impl.
I was also thinking that implementers would want to get from an index to =
an instance so that they could easily handle the various LinePatterns. =
Rather, I'd like to be able to go from an instance of LinePattern =
directly to some code for handling that LinePattern. But I was imagining =
all that code to be tucked away in the impl. This is not what I want to =
do:
if (LinePattern.NONE =3D=3D a_pattern) {
// do some code for none.
} else if (LinePattern.DASHED =3D=3D a_pattern) {
// do some dashed code
}
Rather something like this:
LinePatternImplementation impl =3D dashed_pattern_impl;
if (a_pattern.getValue() < map_line_pattern_to_impl.length) {
LinePatternImplementation impl =3D =
map_line_pattern_to_impl[a_pattern.getValue()];
}
impl.doSomeCodeForYourStyle(...);
How to build map_line_pattern_to_impl for my Geobject implementation.
One time code like this?
static LinePatternImplementation[] map_line_pattern_to_impl;
static void buildPatternMapping() {
map_line_pattern_to_impl =3D new =
LinePatternImplementation[LinePattern.getNumberOfPatterns()];
static class Pair {
public Pair(LinePattern s, LinePatternImplementation i) { m_pattern =
=3D s; m_impl =3D i; }
public LinePattern m_pattern;
public LinePatternImplementation m_impl;
};
Pair[] pairs =3D {
new Pair(LinePattern.NONE, LinePatternImpl.NONE),
new Pair(LinePattern.DASHED, LinePatternImpl.DASHED),
new Pair(LinePattern.DOTTED, LinePatternImpl.NOT_SUPPORTED),
...
}
for (int i =3D 0; i < pairs.length; i++) {
map_line_pattern_to_impl[pairs[i].m_pattern.getValue()] =3D =
pairs[i].m_impl];
}
// sparse fix up nulls
for (int i =3D 0; i < map_line_pattern_to_impl.length; i++) {
if (map_line_pattern_to_impl[i] =3D=3D null) {
map_line_pattern_to_impl[i] =3D LinePatternImpl.NOT_SUPPORTED;
}
}
=20
}
pairs should also be the source to GeobjectCapabilites...
Robert
----- Original Message -----=20
From: jesse crossley=20
To: Robert Hastings (old)=20
Cc: geo...@li... ; Dale McIntosh=20
Sent: Monday, December 09, 2002 6:28 PM
Subject: Re: [Geobject-core] Re: Geobject meeting
i can dynamically update the array as new styles are created.=20
see the attached code.=20
it seems to be (mostly) a huge pain,=20
so i'm thinking i'll rip out my code that used to care about storing =
out the=20
odder style parameters for the time being.=20
(and i'm not sure if it's a simple matter of serializing or not,=20
as my overlay objects were doing weird LeifReference (XIS specific) =
things=20
in order to restore themselves).=20
i dunno if what i was thinking of last week in LinePattern makes any =
sense,=20
but at least i could get further in my compile of the new XIS =
Geobject2.0impl ;->=20
but as DashPattern extends LinePattern and due to the way i made =
things add=20
themselves to the complete array, any LinePattern or subclass instance =
of=20
LinePattern should make it into this array.=20
but it's prolly not safe, as i rarely seem to think through all of the =
cases where=20
someone could go in and break my code.=20
=20
jdc=20
=20
"Robert Hastings (old)" wrote:=20
I'm probably confused, but it seems like GeobjectCapabilities (GC =
is garbage collection in another context) is THE place where you know =
all of the LineStyles your implementation supports not LineStyle. Why is =
it easier to have the array at LineStyle and not GeobjectCapabilities? =
Most impl's cannot just call getArray on LineStyle because they don't =
support every line style (I guess you can see I'm pretty must against =
LineStyle.getArray). Since we allow styles to be created that did not =
exist before the style must contain all the information an =
implementation will need to render it. Many implementations will not =
support user defined line styles, yet another capability? Otherwise, we =
could allow these created styles to be registered with capabilities so =
that anyone asking for what can be done can rendevou there. However, I'm =
leaning on created styles being managed by the outer framework. OK, so =
what your really after is a way to serialize line style. Should we just =
make the LineStyle Serializable. "Effective Java" decribes a way to make =
enum's serializable: public class LineStyle implements Serializable { =
private static int next_ordinal =3D 0; private final int ordinal =3D =
next_ordianl++; private static final LineStyle[] private_values =3D { =
LINE_STYLE1, LINE_STYLE2, ... } private Object readResolve() throws =
ObjectStreamException { return private_values[ordinal]; }} The only =
problem with this approach is that we we later add a LINE_STYLE to the =
spec or remove one all of the ordinals will move. We can either agree to =
maintain the ordering by, allways adding to the end and replacing =
removed contants with dummy values, or we can try to use strings for =
each, ala a hashmap. However, even with a hashmap if we remove a line =
style in the future we will cause problems since the style will not =
resolve once removed. We can agree never to remove a style, just mark it =
as deprecated. User defined should store all of the state a geobject =
impl will need to draw the line style. Again all this could be done =
outside of Geobject. So that Geobject itself is not serializable, but =
your application framework makes serializable objects to store in files, =
etc. public class LineStyleState implements Serializable { private =
transient LineStyle m_line_style; private int ordinal; public =
LineStyleState(GeobjectCapabilities gcap, LineStyle wrapped_style) { =
LineStyle[] styles =3D gcap.getLineStyles(); for (int i =3D 0; i < =
styles.length; i++ ) { if (styles[i] =3D=3D wrapped_style) { =
ordinal =3D i; } } LineStyle getStyle() { return m_line_style; =
}} public class CustomLineStyleState implements Serializable { private =
transient LineStyle m_line_style; private int[] pixels_on_off; private =
Object readResolve() throws ObjectStreamException { return new =
LineStyleState(pixels_on_off); } public getStyle() { return =
m_line_style; } public LineStyleStyle(int []p) { m_line_style =3D new =
LineStyle(p); }}=20
----- Original Message -----
From: jesse crossley
To: Robert Hastings (old)
Cc: geo...@li... ; Dale McIntosh
Sent: Monday, December 09, 2002 1:06 PM
Subject: Re: [Geobject-core] Re: Geobject meeting
because unless it is very craftily written,=20
you don't actually get all of the styles or patterns,=20
especially now that they are all concrete classes=20
and users can make their own instances of them.=20
in our impl of GeobjectCapabilities, anyway,=20
we returned hardcoded arrays of styles and patterns=20
but i don't think that'll work anymore. currently,=20
i would impl the GC method by having it call the static=20
method on the style/pattern class.=20
i added the getArray() method just because it was a simple=20
thing to put in there. what i really wanted was the=20
getThingByValue(int) methods. we serialize a lot of our=20
objects, and so i need to somehow store the patterns and=20
styles. if i store the int value, then MOST of the time i can=20
restore it by fetching the style/pattern by value. obviously,=20
for userdefined things, this ain't gonna work, but at least i'm=20
trying...=20
"Robert Hastings (old)" wrote:=20
Jesse, If you want all line patterns why not just call public =
LineStyle[] getSupportedLineStyles();RobertOne who misses meetings.=20
----- Original Message -----
From: jesse crossley
To: geo...@li...
Cc: Dale McIntosh
Sent: Monday, December 09, 2002 12:20 PM
Subject: [Geobject-core] Re: Geobject meeting
still need to discuss the use of OrientationSources, as not =
everyone is satisfied with the new usage.=20
need to discuss the possibility of overloading some primitive =
methods with LatLonAlt instead of just=20
CoordinateSource to save time and pain within the primitive =
methods.=20
tasks now assigned to me:=20
62718: copy Style.implHints=20
(i assume this just needs to be noted in the =
setPropertiesFrom method? this is actually gonna be a pain,=20
because we don't have any way to get the implHint keys. =
we could just say that in java the implHints must=20
be a Map, and then we could getImplHints and copy the Map =
into our new one)=20
62769: unit params missing=20
i'll keep looking. i noticed that GeoIcon's setRotation =
was wrong (not yet taking an OrientationSource)=20
but most of the rest looked good.=20
60937: resolve consume on GeobjectEvent.=20
why don't we just make concrete Event classes? is there =
anything to be gained by leaving them as interfaces?=20
67308: combine the EnumerationTypes.=20
have the code working on my machine, just need to check it =
in. BUT, while digging through the ETs and extending=20
classes, it seemed to me that we could still offer a =
'getPatternByValue' or 'getStyleByValue' even though we have=20
things like DashPattern extending LinePattern. we REALLY =
need this capability, even if it won't necessarily jive=20
between the times we run a GeobjectImpl. for example, =
maybe i create three LinePatterns. the code i worked on=20
will put the new LinePatterns in the array of all =
LinePatterns, LinePattern then has a static getArray() method (which=20
should return a clone for safety) and a static =
getPatternByValue(int) method. however, the next time i run, maybe=20
i don't create the three LinePatterns, and so requesting =
one of them by value could fail or return a different pattern=20
altogether. but at least within one running of a JVM i =
could get ahold of all LinePatterns. let me know if you want=20
to see the code before i check it in.=20
add get/setLabelColor to Style=20
and thoroughly document everything. my intention is to =
doc as follows: labelColor is the color for a Geobject's label=20
(which is specified within its Style object). foreground =
is for foreground colors (line colors, icon colors, GeoLabel's text=20
color), background is for background colors (fills, =
essentially).=20
this will create a difference from the Jm text object =
thingy, but if i recall correctly, this behaviour was okay with those of =
us that bothered to come to last week's meeting...=20
document that Canvases should accept other Impls' Geobjects.=20
(a documentation task, should outline possible =
implementation)=20
add Map2DCanvasCapabilities (should also have =
GeoCanvasCapabilities then, too, separate from GeobjectCapabilities?)=20
the Map2D version will add the getSupportedProjections() =
method.=20
=20
remaining questions:=20
what does 'add the URL methods to GeoIcon and =
GeoScaledImage' mean?=20
=20
that's about all i've got from the mediocre notes i took. =
anyone recall anything i missed?=20
=20
jdc=20
=20
Rich Kadel wrote:=20
Dale, Jesse,Can you send me the decisions made yesterday and =
any actions assigned? Are we going to make the concrete LatLonAlt and =
other coord classes "new"able?Thanks,Rich -- Rich Kadel=20
Chief Technology Officer=20
Polexis, Inc.=20
Direct: 619-542-7213=20
Fax: 619-542-8675=20
http://www.polexis.com/=20
transforming data into knowledge
|
|
From: Robert H. \(old\) <rha...@sa...> - 2002-12-09 23:16:38
|
I'm probably confused, but it seems like GeobjectCapabilities (GC is =
garbage collection in another context) is THE place where you know all =
of the LineStyles your implementation supports not LineStyle. Why is it =
easier to have the array at LineStyle and not GeobjectCapabilities? =
Most impl's cannot just call getArray on LineStyle because they don't =
support every line style (I guess you can see I'm pretty must against =
LineStyle.getArray).
Since we allow styles to be created that did not exist before the style =
must contain all the information an implementation will need to render =
it. Many implementations will not support user defined line styles, yet =
another capability? Otherwise, we could allow these created styles to be =
registered with capabilities so that anyone asking for what can be done =
can rendevou there. However, I'm leaning on created styles being managed =
by the outer framework.
OK, so what your really after is a way to serialize line style. Should =
we just make the LineStyle Serializable. "Effective Java" decribes a way =
to make enum's serializable:
public class LineStyle implements Serializable {
private static int next_ordinal =3D 0;
private final int ordinal =3D next_ordianl++;
private static final LineStyle[] private_values =3D { LINE_STYLE1, =
LINE_STYLE2, ... }
private Object readResolve() throws ObjectStreamException {
return private_values[ordinal];
}
}
The only problem with this approach is that we we later add a LINE_STYLE =
to the spec or remove one all of the ordinals will move. We can either =
agree to maintain the ordering by, allways adding to the end and =
replacing removed contants with dummy values, or we can try to use =
strings for each, ala a hashmap. However, even with a hashmap if we =
remove a line style in the future we will cause problems since the style =
will not resolve once removed. We can agree never to remove a style, =
just mark it as deprecated.
User defined should store all of the state a geobject impl will need to =
draw the line style. Again all this could be done outside of Geobject. =
So that Geobject itself is not serializable, but your application =
framework makes serializable objects to store in files, etc.
public class LineStyleState implements Serializable {
private transient LineStyle m_line_style;
private int ordinal;
public LineStyleState(GeobjectCapabilities gcap, LineStyle =
wrapped_style) {
LineStyle[] styles =3D gcap.getLineStyles();
for (int i =3D 0; i < styles.length; i++ ) {
if (styles[i] =3D=3D wrapped_style) {
ordinal =3D i;
}
}
LineStyle getStyle() { return m_line_style; }
}
public class CustomLineStyleState implements Serializable {
private transient LineStyle m_line_style;
private int[] pixels_on_off;
private Object readResolve() throws ObjectStreamException {
return new LineStyleState(pixels_on_off);
}
public getStyle() { return m_line_style; }
public LineStyleStyle(int []p) { m_line_style =3D new LineStyle(p); }
}
----- Original Message -----=20
From: jesse crossley=20
To: Robert Hastings (old)=20
Cc: geo...@li... ; Dale McIntosh=20
Sent: Monday, December 09, 2002 1:06 PM
Subject: Re: [Geobject-core] Re: Geobject meeting
because unless it is very craftily written,=20
you don't actually get all of the styles or patterns,=20
especially now that they are all concrete classes=20
and users can make their own instances of them.=20
in our impl of GeobjectCapabilities, anyway,=20
we returned hardcoded arrays of styles and patterns=20
but i don't think that'll work anymore. currently,=20
i would impl the GC method by having it call the static=20
method on the style/pattern class.=20
i added the getArray() method just because it was a simple=20
thing to put in there. what i really wanted was the=20
getThingByValue(int) methods. we serialize a lot of our=20
objects, and so i need to somehow store the patterns and=20
styles. if i store the int value, then MOST of the time i can=20
restore it by fetching the style/pattern by value. obviously,=20
for userdefined things, this ain't gonna work, but at least i'm=20
trying...=20
"Robert Hastings (old)" wrote:=20
Jesse, If you want all line patterns why not just call public =
LineStyle[] getSupportedLineStyles();RobertOne who misses meetings.=20
----- Original Message -----
From: jesse crossley
To: geo...@li...
Cc: Dale McIntosh
Sent: Monday, December 09, 2002 12:20 PM
Subject: [Geobject-core] Re: Geobject meeting
still need to discuss the use of OrientationSources, as not =
everyone is satisfied with the new usage.=20
need to discuss the possibility of overloading some primitive =
methods with LatLonAlt instead of just=20
CoordinateSource to save time and pain within the primitive =
methods.=20
tasks now assigned to me:=20
62718: copy Style.implHints=20
(i assume this just needs to be noted in the setPropertiesFrom =
method? this is actually gonna be a pain,=20
because we don't have any way to get the implHint keys. we =
could just say that in java the implHints must=20
be a Map, and then we could getImplHints and copy the Map =
into our new one)=20
62769: unit params missing=20
i'll keep looking. i noticed that GeoIcon's setRotation was =
wrong (not yet taking an OrientationSource)=20
but most of the rest looked good.=20
60937: resolve consume on GeobjectEvent.=20
why don't we just make concrete Event classes? is there =
anything to be gained by leaving them as interfaces?=20
67308: combine the EnumerationTypes.=20
have the code working on my machine, just need to check it in. =
BUT, while digging through the ETs and extending=20
classes, it seemed to me that we could still offer a =
'getPatternByValue' or 'getStyleByValue' even though we have=20
things like DashPattern extending LinePattern. we REALLY need =
this capability, even if it won't necessarily jive=20
between the times we run a GeobjectImpl. for example, maybe i =
create three LinePatterns. the code i worked on=20
will put the new LinePatterns in the array of all =
LinePatterns, LinePattern then has a static getArray() method (which=20
should return a clone for safety) and a static =
getPatternByValue(int) method. however, the next time i run, maybe=20
i don't create the three LinePatterns, and so requesting one =
of them by value could fail or return a different pattern=20
altogether. but at least within one running of a JVM i could =
get ahold of all LinePatterns. let me know if you want=20
to see the code before i check it in.=20
add get/setLabelColor to Style=20
and thoroughly document everything. my intention is to doc as =
follows: labelColor is the color for a Geobject's label=20
(which is specified within its Style object). foreground is =
for foreground colors (line colors, icon colors, GeoLabel's text=20
color), background is for background colors (fills, =
essentially).=20
this will create a difference from the Jm text object thingy, =
but if i recall correctly, this behaviour was okay with those of=20
us that bothered to come to last week's meeting...=20
document that Canvases should accept other Impls' Geobjects.=20
(a documentation task, should outline possible implementation) =
add Map2DCanvasCapabilities (should also have =
GeoCanvasCapabilities then, too, separate from GeobjectCapabilities?)=20
the Map2D version will add the getSupportedProjections() =
method.=20
=20
remaining questions:=20
what does 'add the URL methods to GeoIcon and GeoScaledImage' =
mean?=20
=20
that's about all i've got from the mediocre notes i took. anyone =
recall anything i missed?=20
=20
jdc=20
=20
Rich Kadel wrote:=20
Dale, Jesse,Can you send me the decisions made yesterday and any =
actions assigned? Are we going to make the concrete LatLonAlt and other =
coord classes "new"able?Thanks,Rich -- Rich Kadel=20
Chief Technology Officer=20
Polexis, Inc.=20
Direct: 619-542-7213=20
Fax: 619-542-8675=20
http://www.polexis.com/=20
transforming data into knowledge
|
|
From: jesse c. <cro...@po...> - 2002-12-09 21:07:13
|
because unless it is very craftily written, you don't actually get all of the styles or patterns, especially now that they are all concrete classes and users can make their own instances of them. in our impl of GeobjectCapabilities, anyway, we returned hardcoded arrays of styles and patterns but i don't think that'll work anymore. currently, i would impl the GC method by having it call the static method on the style/pattern class. i added the getArray() method just because it was a simple thing to put in there. what i really wanted was the getThingByValue(int) methods. we serialize a lot of our objects, and so i need to somehow store the patterns and styles. if i store the int value, then MOST of the time i can restore it by fetching the style/pattern by value. obviously, for userdefined things, this ain't gonna work, but at least i'm trying... "Robert Hastings (old)" wrote: > Jesse, If you want all line patterns why not just call public > LineStyle[] getSupportedLineStyles();RobertOne who misses meetings. > > ----- Original Message ----- > From: jesse crossley > To: geo...@li... > Cc: Dale McIntosh > Sent: Monday, December 09, 2002 12:20 PM > Subject: [Geobject-core] Re: Geobject meeting > still need to discuss the use of OrientationSources, as not > everyone is satisfied with the new usage. > > need to discuss the possibility of overloading some > primitive methods with LatLonAlt instead of just > CoordinateSource to save time and pain within the primitive > methods. > > tasks now assigned to me: > > 62718: copy Style.implHints > (i assume this just needs to be noted in the > setPropertiesFrom method? this is actually gonna be a pain, > > because we don't have any way to get the implHint > keys. we could just say that in java the implHints must > be a Map, and then we could getImplHints and copy the > Map into our new one) > > 62769: unit params missing > i'll keep looking. i noticed that GeoIcon's setRotation > was wrong (not yet taking an OrientationSource) > but most of the rest looked good. > > 60937: resolve consume on GeobjectEvent. > why don't we just make concrete Event classes? is there > anything to be gained by leaving them as interfaces? > > 67308: combine the EnumerationTypes. > have the code working on my machine, just need to check > it in. BUT, while digging through the ETs and extending > classes, it seemed to me that we could still offer a > 'getPatternByValue' or 'getStyleByValue' even though we have > > things like DashPattern extending LinePattern. we > REALLY need this capability, even if it won't necessarily > jive > between the times we run a GeobjectImpl. for example, > maybe i create three LinePatterns. the code i worked on > will put the new LinePatterns in the array of all > LinePatterns, LinePattern then has a static getArray() > method (which > should return a clone for safety) and a static > getPatternByValue(int) method. however, the next time i > run, maybe > i don't create the three LinePatterns, and so requesting > one of them by value could fail or return a different > pattern > altogether. but at least within one running of a JVM i > could get ahold of all LinePatterns. let me know if you > want > to see the code before i check it in. > > add get/setLabelColor to Style > and thoroughly document everything. my intention is to > doc as follows: labelColor is the color for a Geobject's > label > (which is specified within its Style object). > foreground is for foreground colors (line colors, icon > colors, GeoLabel's text > color), background is for background colors (fills, > essentially). > this will create a difference from the Jm text object > thingy, but if i recall correctly, this behaviour was okay > with those of > us that bothered to come to last week's meeting... > > document that Canvases should accept other Impls' Geobjects. > > (a documentation task, should outline possible > implementation) > > add Map2DCanvasCapabilities (should also have > GeoCanvasCapabilities then, too, separate from > GeobjectCapabilities?) > the Map2D version will add the getSupportedProjections() > method. > > > remaining questions: > what does 'add the URL methods to GeoIcon and > GeoScaledImage' mean? > > > that's about all i've got from the mediocre notes i took. > anyone recall anything i missed? > > > jdc > > > Rich Kadel wrote: > > > Dale, Jesse,Can you send me the decisions made yesterday > > and any actions assigned? Are we going to make the > > concrete LatLonAlt and other coord classes > > "new"able?Thanks,Rich -- Rich Kadel > > Chief Technology Officer > > Polexis, Inc. > > Direct: 619-542-7213 > > Fax: 619-542-8675 > > http://www.polexis.com/ > > transforming data into knowledge > |
|
From: Robert H. \(old\) <rha...@sa...> - 2002-12-09 20:59:36
|
Jesse,
If you want all line patterns why not just call=20
public LineStyle[] getSupportedLineStyles();
Robert
One who misses meetings.
----- Original Message -----=20
From: jesse crossley=20
To: geo...@li...=20
Cc: Dale McIntosh=20
Sent: Monday, December 09, 2002 12:20 PM
Subject: [Geobject-core] Re: Geobject meeting
still need to discuss the use of OrientationSources, as not everyone =
is satisfied with the new usage.=20
need to discuss the possibility of overloading some primitive methods =
with LatLonAlt instead of just=20
CoordinateSource to save time and pain within the primitive methods.=20
tasks now assigned to me:=20
62718: copy Style.implHints=20
(i assume this just needs to be noted in the setPropertiesFrom =
method? this is actually gonna be a pain,=20
because we don't have any way to get the implHint keys. we could =
just say that in java the implHints must=20
be a Map, and then we could getImplHints and copy the Map into =
our new one)=20
62769: unit params missing=20
i'll keep looking. i noticed that GeoIcon's setRotation was wrong =
(not yet taking an OrientationSource)=20
but most of the rest looked good.=20
60937: resolve consume on GeobjectEvent.=20
why don't we just make concrete Event classes? is there anything =
to be gained by leaving them as interfaces?=20
67308: combine the EnumerationTypes.=20
have the code working on my machine, just need to check it in. =
BUT, while digging through the ETs and extending=20
classes, it seemed to me that we could still offer a =
'getPatternByValue' or 'getStyleByValue' even though we have=20
things like DashPattern extending LinePattern. we REALLY need =
this capability, even if it won't necessarily jive=20
between the times we run a GeobjectImpl. for example, maybe i =
create three LinePatterns. the code i worked on=20
will put the new LinePatterns in the array of all LinePatterns, =
LinePattern then has a static getArray() method (which=20
should return a clone for safety) and a static =
getPatternByValue(int) method. however, the next time i run, maybe=20
i don't create the three LinePatterns, and so requesting one of =
them by value could fail or return a different pattern=20
altogether. but at least within one running of a JVM i could get =
ahold of all LinePatterns. let me know if you want=20
to see the code before i check it in.=20
add get/setLabelColor to Style=20
and thoroughly document everything. my intention is to doc as =
follows: labelColor is the color for a Geobject's label=20
(which is specified within its Style object). foreground is for =
foreground colors (line colors, icon colors, GeoLabel's text=20
color), background is for background colors (fills, essentially).=20
this will create a difference from the Jm text object thingy, but =
if i recall correctly, this behaviour was okay with those of=20
us that bothered to come to last week's meeting...=20
document that Canvases should accept other Impls' Geobjects.=20
(a documentation task, should outline possible implementation)=20
add Map2DCanvasCapabilities (should also have GeoCanvasCapabilities =
then, too, separate from GeobjectCapabilities?)=20
the Map2D version will add the getSupportedProjections() method.=20
=20
remaining questions:=20
what does 'add the URL methods to GeoIcon and GeoScaledImage' =
mean?=20
=20
that's about all i've got from the mediocre notes i took. anyone =
recall anything i missed?=20
=20
jdc=20
=20
Rich Kadel wrote:=20
Dale, Jesse,Can you send me the decisions made yesterday and any =
actions assigned? Are we going to make the concrete LatLonAlt and other =
coord classes "new"able?Thanks,Rich -- Rich Kadel=20
Chief Technology Officer=20
Polexis, Inc.=20
Direct: 619-542-7213=20
Fax: 619-542-8675=20
http://www.polexis.com/=20
transforming data into knowledge=20
|
|
From: jesse c. <cro...@po...> - 2002-12-09 20:21:48
|
still need to discuss the use of OrientationSources, as not everyone is
satisfied with the new usage.
need to discuss the possibility of overloading some primitive methods
with LatLonAlt instead of just
CoordinateSource to save time and pain within the primitive methods.
tasks now assigned to me:
62718: copy Style.implHints
(i assume this just needs to be noted in the setPropertiesFrom
method? this is actually gonna be a pain,
because we don't have any way to get the implHint keys. we could
just say that in java the implHints must
be a Map, and then we could getImplHints and copy the Map into our
new one)
62769: unit params missing
i'll keep looking. i noticed that GeoIcon's setRotation was wrong
(not yet taking an OrientationSource)
but most of the rest looked good.
60937: resolve consume on GeobjectEvent.
why don't we just make concrete Event classes? is there anything to
be gained by leaving them as interfaces?
67308: combine the EnumerationTypes.
have the code working on my machine, just need to check it in. BUT,
while digging through the ETs and extending
classes, it seemed to me that we could still offer a
'getPatternByValue' or 'getStyleByValue' even though we have
things like DashPattern extending LinePattern. we REALLY need this
capability, even if it won't necessarily jive
between the times we run a GeobjectImpl. for example, maybe i
create three LinePatterns. the code i worked on
will put the new LinePatterns in the array of all LinePatterns,
LinePattern then has a static getArray() method (which
should return a clone for safety) and a static
getPatternByValue(int) method. however, the next time i run, maybe
i don't create the three LinePatterns, and so requesting one of them
by value could fail or return a different pattern
altogether. but at least within one running of a JVM i could get
ahold of all LinePatterns. let me know if you want
to see the code before i check it in.
add get/setLabelColor to Style
and thoroughly document everything. my intention is to doc as
follows: labelColor is the color for a Geobject's label
(which is specified within its Style object). foreground is for
foreground colors (line colors, icon colors, GeoLabel's text
color), background is for background colors (fills, essentially).
this will create a difference from the Jm text object thingy, but if
i recall correctly, this behaviour was okay with those of
us that bothered to come to last week's meeting...
document that Canvases should accept other Impls' Geobjects.
(a documentation task, should outline possible implementation)
add Map2DCanvasCapabilities (should also have GeoCanvasCapabilities
then, too, separate from GeobjectCapabilities?)
the Map2D version will add the getSupportedProjections() method.
remaining questions:
what does 'add the URL methods to GeoIcon and GeoScaledImage' mean?
that's about all i've got from the mediocre notes i took. anyone recall
anything i missed?
jdc
Rich Kadel wrote:
> Dale, Jesse,Can you send me the decisions made yesterday and any
> actions assigned? Are we going to make the concrete LatLonAlt and
> other coord classes "new"able?Thanks,Rich -- Rich Kadel
> Chief Technology Officer
> Polexis, Inc.
> Direct: 619-542-7213
> Fax: 619-542-8675
> http://www.polexis.com/
> transforming data into knowledge
|
|
From: jesse c. <cro...@po...> - 2002-11-28 02:23:41
|
Messageheh, i did say it was debatable... but yeah, that's what i meant by it being (possibly) a new PlanarAngle. our converts are coded to return the OrientationSource if it is already the right type of object we want to convert to. but the single cases aren't so terrible, just tedious. the calls to setArc(with_all_those_params) get a bit more hairy, as we now need to make the three OrientationSources, but c'est la vie. i changed a couple of our setArc calls over to the new methodology today and it seemed reasonable. =20 i will definitely look into having other classes (especially Overlays = but also Drawables if possible) hold onto the OrientationSources (and all other Sources for that matter) that they set on representative Geobjects. so, in theory, i could have an ArcOverlay that held the three = OrientationSources and set them on all the Geobjects that were created for it. so if the = ArcOverlay changes its start angle, all of the representative GeoArcs should get = the update as well. hmm...it sounds good, but it'll prolly get messy somewhere in=20 the details. ----- Original Message -----=20 From: Rich Kadel=20 To: Jesse Crossley ; geo...@li...=20 Sent: Wednesday, 27 November 2002 5:53 pm Subject: RE: [Geobject-core] ARS (or the lack thereof) and other = things Well, most of the time you know what you're working with in the case = of my example, so my code would work in those cases. That was my = assumption. =20 Actually, your example won't work because you've created a new = PlanarAngle (during the call to convert), and haven't set it on the Arc. -- Rich Kadel Chief Technology Officer Polexis, Inc. Direct: 619-542-7213 Fax: 619-542-8675 http://www.polexis.com/ transforming data into knowledge -----Original Message----- From: Jesse Crossley=20 Sent: Wednesday, November 27, 2002 5:02 PM To: geo...@li... Subject: Re: [Geobject-core] ARS (or the lack thereof) and other = things If you don't want to hold on to the angle separately, just call: = ((PlanarAngle)arc.getOrientation()).setAngle(3.1415, Angle.radians); except this could lead to class cast exceptions, cos we're only = guaranteed=20 an OrientationSource, not a PlanarAngle. to oneline it, we'd hafta = call:=20 = ((PlanarAngle)arc.getOrientation().getOrientation().convert(PlanarAngle.c= lass, null)).setAngle(3.1415, SI.RADIAN);=20 ...and it's debatable whether i even got that line right...=20 and then, we'd have a new PlanarAngle (possibly, anyway), not the = arc's real OrientationSource,=20 so there isn't a way to oneline it, i don't think.=20 so if we want to make use of the OrientationSource's event firing, = we must hang onto=20 the angle for the life of the arc? eesh, ima gonna just make new = Orientations whenever i need 'em.=20 there may be some cases where i can hang onto the original = Orientation i assign to the arc,=20 but i don't anticipate very many.=20 =20 jdc=20 =20 |
|
From: Rich K. <ka...@po...> - 2002-11-28 01:54:13
|
Well, most of the time you know what you're working with in the case of my example, so my code would work in those cases. That was my assumption. =20 Actually, your example won't work because you've created a new PlanarAngle (during the call to convert), and haven't set it on the Arc. =20 =20 -- =20 Rich Kadel Chief Technology Officer Polexis, Inc. Direct: 619-542-7213 Fax: 619-542-8675 http://www.polexis.com/ transforming data into knowledge -----Original Message----- From: Jesse Crossley=20 Sent: Wednesday, November 27, 2002 5:02 PM To: geo...@li... Subject: Re: [Geobject-core] ARS (or the lack thereof) and other things =09 =09 If you don't want to hold on to the angle separately, just call: ((PlanarAngle)arc.getOrientation()).setAngle(3.1415, Angle.radians); =09 except this could lead to class cast exceptions, cos we're only guaranteed=20 an OrientationSource, not a PlanarAngle. to oneline it, we'd hafta call:=20 =09 ((PlanarAngle)arc.getOrientation().getOrientation().convert(PlanarAngle. class, null)).setAngle(3.1415, SI.RADIAN);=20 ...and it's debatable whether i even got that line right...=20 and then, we'd have a new PlanarAngle (possibly, anyway), not the arc's real OrientationSource,=20 so there isn't a way to oneline it, i don't think.=20 so if we want to make use of the OrientationSource's event firing, we must hang onto=20 the angle for the life of the arc? eesh, ima gonna just make new Orientations whenever i need 'em.=20 there may be some cases where i can hang onto the original Orientation i assign to the arc,=20 but i don't anticipate very many.=20 =20 jdc=20 =20 |
|
From: jesse c. <cro...@po...> - 2002-11-28 01:03:26
|
> If you don't want to hold on to the angle separately, just call: > ((PlanarAngle)arc.getOrientation()).setAngle(3.1415, Angle.radians); except this could lead to class cast exceptions, cos we're only guaranteed an OrientationSource, not a PlanarAngle. to oneline it, we'd hafta call: ((PlanarAngle)arc.getOrientation().getOrientation().convert(PlanarAngle.class, null)).setAngle(3.1415, SI.RADIAN); ...and it's debatable whether i even got that line right... and then, we'd have a new PlanarAngle (possibly, anyway), not the arc's real OrientationSource, so there isn't a way to oneline it, i don't think. so if we want to make use of the OrientationSource's event firing, we must hang onto the angle for the life of the arc? eesh, ima gonna just make new Orientations whenever i need 'em. there may be some cases where i can hang onto the original Orientation i assign to the arc, but i don't anticipate very many. jdc |
|
From: Rich K. <ka...@po...> - 2002-11-28 00:45:32
|
Woops...Just thought about that reusability issue. Well, if it is an
OrientationSource, changing the angle will fire a change event.
=20
In otherwords, PLEASE DOCUMENT THE BEHAVIOR, because it might be
non-intuitive sometimes...
=20
If you want to reset the angle, just call:
=20
angle.setAngle(45, Angle.degrees);
=20
You don't need to do anything else, because PlanarAngle should fire a
change event and the Arc should pick it up.
=20
If you don't want to hold on to the angle separately, just call:
=20
((PlanarAngle)arc.getOrientation()).setAngle(3.1415, Angle.radians);
=20
YOU PROBABLY SHOULD DOCUMENT the following example of what NOT to do
(normally):
=20
angle.setAngle(90, Angle.degrees);
arc1.setOrientation(angle);
=20
angle.setAngle(270, Angle.degrees);
arc2.setOrientation(angle);
=20
This will give you two arcs with the same angle, because arc1 is holding
on to the angle object and listening for changes.
=20
Rich
=20
--
=20
Rich Kadel
Chief Technology Officer
Polexis, Inc.
Direct: 619-542-7213
Fax: 619-542-8675
http://www.polexis.com/
transforming data into knowledge
-----Original Message-----
From: Rich Kadel=20
Sent: Wednesday, November 27, 2002 4:29 PM
To: Jesse Crossley; geo...@li...
Subject: RE: [Geobject-core] ARS (or the lack thereof) and other
things
=09
=09
Jesse,=20
1. OrientationSource is important, because the source may
change. As we do with CoordinateSource (or used to at least), you
should be listening for SourceChangeEvents and adjusting the Arc as
necessary. Yes, it's a bit verbose, but the angles are reusable:
PlanarAngle angle =3D
orientationFactory.createOrientation(PlanarAngle.class);=20
...=20
angle.setAngle(90, Angle.degrees);=20
arc.setOrientation(angle);=20
Or:=20
arc.setOrientation(someShip.getBearing());=20
2. WRT, "why did we decide that GeoArc stroked COUNTERclockwise
from start to end?", I don't remember it specifically, but I vaguely
recall that for planar angles (starting along the X axis) it is natural
that angles go counter-clockwise (I think). On the other hand, if most
APIs go clockwise (e.g., Java2D, Microsoft, etc.), then I would think we
could do that too. (I haven't looked.)
3. I think you should upgrade to the latest JADE (I'm hoping it
is getting close to what the Java API will include, but who knows).
4. No strong opinion on the other things at the moment, but I
would like to review it at our meeting on the 5th.=20
Thanks,=20
Rich=20
--=20
=20
Rich Kadel=20
Chief Technology Officer=20
Polexis, Inc.=20
Direct: 619-542-7213=20
Fax: 619-542-8675=20
http://www.polexis.com/=20
transforming data into knowledge=20
-----Original Message-----=20
From: Jesse Crossley=20
Sent: Wednesday, November 27, 2002 3:00 PM=20
To: geo...@li...=20
Subject: [Geobject-core] ARS (or the lack thereof) and other
things=20
as i began to modify our impl of GeoArc,=20
i was struck by how painful it is to use OrientationSources=20
for the orientation, start, and end angles.=20
i also observed that it would be possible to send in different
OrientationSource classes for each value and i wondered about the
correctness of such a usage.
i fail to understand the logic behind what happened to GeoArc
(mebbe i just missed something?). why are we sending in
OrientationSources instead of doubles and some sort of marker (like the
units, or the phantom ARS constants) to tell what type of angles the
doubles represent? if we go the OrienationSource route, then i must
construct OrientationSources every time i wanna change these values and
then i hafta take 'em apart in order to get the actual numeric value i
need to use. if everyone else is cool with that, then i'll go ahead and
make the changes and do it that way... but as a potential Geobject user,
i'm gonna be awfully angry with us every time i hafta use a GeoArc or
need to rotate a GeoLabel when the corresponding methods in other
classes allow me to use my existing value and simply specify it with a
unit. as a Geobject user, i'm happy to add Units to my method calls to
ensure that values are set as i expect, but when i hafta go outta my way
to make an OrientationSource to rotate something, then i'm gonna curse
Geobject loud and long. and why did we decide that GeoArc stroked
COUNTERclockwise from start to end? i hafta go change ALOT of code for
this and wondered what the rationalization was.
also, should we upgrade to JADE 3.1? i appear to have been
reading and working from that JavaDoc rather than the 2.0 version. units
are split into two constants classes: SI and NonSI (so no more Length.*
things)
(Rich: NonSI does have Nautical Miles and Degrees,=20
they just weren't in the website's JavaDoc, so i don't need=20
to write the Unit classes after all).=20
also2, i intend to add getCoordinateList to GeobjectManager as a
convenience method unless someone objects. (i kinda think both it and
the CoordinateFactory.getCoordinateList method should be called
createCoordinateList, but that's just to match existing naming
conventions).
also3, i've modified the GeobjectListenerSupport so that it now
has a constructor that takes a Geobject. in its fireMouse*** methods,
then, it checks its Geobject to see if it is passingEventsToParent and
takes care of it. i'll commit this unless someone has an objection to
it working this way (but we say in the JavaDoc that this is s'posed to
happen and this will make it easier for implementors and users).
also4, i've modified GeoVector by adding three basic methods to
the interface and introduced two interfaces between GeoVector and
RangeBearingAzimuth. the inheritance now goes from GeoVector -> RTheta
-> RThetaPhi -> RangeBearingAzimuth. i've attached the first three so
you can review them and agree/disagree that they're suitable to add to
Geobject.
seeing as most everyone will be vacationing already,=20
i'll wait til monday to act on any of these items.=20
hope everyone has/had a good holiday.=20
jdc=20
|
|
From: Rich K. <ka...@po...> - 2002-11-28 00:30:09
|
Jesse, 1. OrientationSource is important, because the source may change. As we do with CoordinateSource (or used to at least), you should be listening for SourceChangeEvents and adjusting the Arc as necessary. Yes, it's a bit verbose, but the angles are reusable: PlanarAngle angle =3D orientationFactory.createOrientation(PlanarAngle.class); ... angle.setAngle(90, Angle.degrees); arc.setOrientation(angle); Or: arc.setOrientation(someShip.getBearing()); 2. WRT, "why did we decide that GeoArc stroked COUNTERclockwise from start to end?", I don't remember it specifically, but I vaguely recall that for planar angles (starting along the X axis) it is natural that angles go counter-clockwise (I think). On the other hand, if most APIs go clockwise (e.g., Java2D, Microsoft, etc.), then I would think we could do that too. (I haven't looked.) 3. I think you should upgrade to the latest JADE (I'm hoping it is getting close to what the Java API will include, but who knows). 4. No strong opinion on the other things at the moment, but I would like to review it at our meeting on the 5th. Thanks, Rich -- =20 Rich Kadel Chief Technology Officer Polexis, Inc. Direct: 619-542-7213 Fax: 619-542-8675 http://www.polexis.com/ transforming data into knowledge -----Original Message----- From: Jesse Crossley=20 Sent: Wednesday, November 27, 2002 3:00 PM To: geo...@li... Subject: [Geobject-core] ARS (or the lack thereof) and other things as i began to modify our impl of GeoArc, i was struck by how painful it is to use OrientationSources for the orientation, start, and end angles. i also observed that it would be possible to send in different OrientationSource classes for each value and i wondered about the correctness of such a usage. i fail to understand the logic behind what happened to GeoArc (mebbe i just missed something?). why are we sending in OrientationSources instead of doubles and some sort of marker (like the units, or the phantom ARS constants) to tell what type of angles the doubles represent? if we go the OrienationSource route, then i must construct OrientationSources every time i wanna change these values and then i hafta take 'em apart in order to get the actual numeric value i need to use. if everyone else is cool with that, then i'll go ahead and make the changes and do it that way... but as a potential Geobject user, i'm gonna be awfully angry with us every time i hafta use a GeoArc or need to rotate a GeoLabel when the corresponding methods in other classes allow me to use my existing value and simply specify it with a unit. as a Geobject user, i'm happy to add Units to my method calls to ensure that values are set as i expect, but when i hafta go outta my way to make an OrientationSource to rotate something, then i'm gonna curse Geobject loud and long. and why did we decide that GeoArc stroked COUNTERclockwise from start to end? i hafta go change ALOT of code for this and wondered what the rationalization was. also, should we upgrade to JADE 3.1? i appear to have been reading and working from that JavaDoc rather than the 2.0 version. units are split into two constants classes: SI and NonSI (so no more Length.* things) (Rich: NonSI does have Nautical Miles and Degrees, they just weren't in the website's JavaDoc, so i don't need to write the Unit classes after all). also2, i intend to add getCoordinateList to GeobjectManager as a convenience method unless someone objects. (i kinda think both it and the CoordinateFactory.getCoordinateList method should be called createCoordinateList, but that's just to match existing naming conventions). also3, i've modified the GeobjectListenerSupport so that it now has a constructor that takes a Geobject. in its fireMouse*** methods, then, it checks its Geobject to see if it is passingEventsToParent and takes care of it. i'll commit this unless someone has an objection to it working this way (but we say in the JavaDoc that this is s'posed to happen and this will make it easier for implementors and users). also4, i've modified GeoVector by adding three basic methods to the interface and introduced two interfaces between GeoVector and RangeBearingAzimuth. the inheritance now goes from GeoVector -> RTheta -> RThetaPhi -> RangeBearingAzimuth. i've attached the first three so you can review them and agree/disagree that they're suitable to add to Geobject. seeing as most everyone will be vacationing already, i'll wait til monday to act on any of these items. hope everyone has/had a good holiday. jdc |
|
From: jesse c. <cro...@po...> - 2002-11-27 23:01:11
|
as i began to modify our impl of GeoArc, i was struck by how painful it is to use OrientationSources for the orientation, start, and end angles. i also observed that it would be possible to send in different OrientationSource classes for each value and i wondered about the correctness of such a usage. i fail to understand the logic behind what happened to GeoArc (mebbe i just missed something?). why are we sending in OrientationSources instead of doubles and some sort of marker (like the units, or the phantom ARS constants) to tell what type of angles the doubles represent? if we go the OrienationSource route, then i must construct OrientationSources every time i wanna change these values and then i hafta take 'em apart in order to get the actual numeric value i need to use. if everyone else is cool with that, then i'll go ahead and make the changes and do it that way... but as a potential Geobject user, i'm gonna be awfully angry with us every time i hafta use a GeoArc or need to rotate a GeoLabel when the corresponding methods in other classes allow me to use my existing value and simply specify it with a unit. as a Geobject user, i'm happy to add Units to my method calls to ensure that values are set as i expect, but when i hafta go outta my way to make an OrientationSource to rotate something, then i'm gonna curse Geobject loud and long. and why did we decide that GeoArc stroked COUNTERclockwise from start to end? i hafta go change ALOT of code for this and wondered what the rationalization was. also, should we upgrade to JADE 3.1? i appear to have been reading and working from that JavaDoc rather than the 2.0 version. units are split into two constants classes: SI and NonSI (so no more Length.* things) (Rich: NonSI does have Nautical Miles and Degrees, they just weren't in the website's JavaDoc, so i don't need to write the Unit classes after all). also2, i intend to add getCoordinateList to GeobjectManager as a convenience method unless someone objects. (i kinda think both it and the CoordinateFactory.getCoordinateList method should be called createCoordinateList, but that's just to match existing naming conventions). also3, i've modified the GeobjectListenerSupport so that it now has a constructor that takes a Geobject. in its fireMouse*** methods, then, it checks its Geobject to see if it is passingEventsToParent and takes care of it. i'll commit this unless someone has an objection to it working this way (but we say in the JavaDoc that this is s'posed to happen and this will make it easier for implementors and users). also4, i've modified GeoVector by adding three basic methods to the interface and introduced two interfaces between GeoVector and RangeBearingAzimuth. the inheritance now goes from GeoVector -> RTheta -> RThetaPhi -> RangeBearingAzimuth. i've attached the first three so you can review them and agree/disagree that they're suitable to add to Geobject. seeing as most everyone will be vacationing already, i'll wait til monday to act on any of these items. hope everyone has/had a good holiday. jdc |
|
From: jesse c. <cro...@po...> - 2002-11-21 18:39:52
|
yeah, that's all i was thinking about on this one. "Robert Hastings (old)" wrote: > Jesse, > Is the core of the issue that you need a way to reset pooled geobjects to > their defaults? > > Robert > ----- Original Message ----- > From: "jesse crossley" <cro...@po...> > To: <geo...@li...> > Cc: <jg...@po...> > Sent: Wednesday, November 20, 2002 3:26 PM > Subject: [Geobject-core] and another thing i just thought about > > > we still have createStyle methods on GeobjectFactory and GeobjectManager > > > > but we don't have Geobject.setStyle() anymore, so is there a need for > > standalone > > Style objects? > > i can still see the value of this method, because we can always > > getStyle().setPropertiesFrom(my_new_and_unattached_style) > > and that's what i'm about to do for some pooled objects i hafta deal > > with > > (when they are returned, we previously would setStyle(null) but i canna > > do > > that anymore). but it seems to me that this functionality could also be > > > > contained within a Style.reset() method (or something similar, you get > > the idea). > > > > any thoughts? i've got no problem with pursuing the aforementioned > > solution, > > but if we can make Geobject use simpler, than it will have a better > > chance at > > acceptance. > > > > > > jdc > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: The Sourceforge Network Survey > > Take Our Survey and You Could Win a $500 Gift Certificate! > > http://ugamsolutions.com/psurvey/osdn/SourceForge/index_sourceforge.htm > > _______________________________________________ > > Geobject-core mailing list > > Geo...@li... > > https://lists.sourceforge.net/lists/listinfo/geobject-core > > |
|
From: Robert H. \(old\) <rha...@sa...> - 2002-11-21 18:04:47
|
Jesse, Is the core of the issue that you need a way to reset pooled geobjects to their defaults? Robert ----- Original Message ----- From: "jesse crossley" <cro...@po...> To: <geo...@li...> Cc: <jg...@po...> Sent: Wednesday, November 20, 2002 3:26 PM Subject: [Geobject-core] and another thing i just thought about > we still have createStyle methods on GeobjectFactory and GeobjectManager > > but we don't have Geobject.setStyle() anymore, so is there a need for > standalone > Style objects? > i can still see the value of this method, because we can always > getStyle().setPropertiesFrom(my_new_and_unattached_style) > and that's what i'm about to do for some pooled objects i hafta deal > with > (when they are returned, we previously would setStyle(null) but i canna > do > that anymore). but it seems to me that this functionality could also be > > contained within a Style.reset() method (or something similar, you get > the idea). > > any thoughts? i've got no problem with pursuing the aforementioned > solution, > but if we can make Geobject use simpler, than it will have a better > chance at > acceptance. > > > jdc > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Sourceforge Network Survey > Take Our Survey and You Could Win a $500 Gift Certificate! > http://ugamsolutions.com/psurvey/osdn/SourceForge/index_sourceforge.htm > _______________________________________________ > Geobject-core mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geobject-core > |
|
From: Robert H. <rha...@mo...> - 2002-11-21 18:02:25
|
Another one. ----- Original Message -----=20 From: Robert Hastings=20 To: geo...@so...=20 Sent: Tuesday, November 19, 2002 10:56 PM Subject: createGeobject/clone Yes, it's the hair loss, but I can't recall why we decided to keep = createGeobject instead of having a clone method? At one point I thought we where thinking of getting rid of both, but... Robert |
|
From: Robert H. <rha...@mo...> - 2002-11-21 18:02:14
|
Oops, sent to the wrong email address.
----- Original Message -----
From: "Robert Hastings" <rha...@mo...>
To: <geo...@so...>
Sent: Tuesday, November 19, 2002 10:54 PM
Subject: Old items from Chris's list (some of which are not done)
> I floated the not done ones to the top of the list...
> Let me know if someone disagrees with the done list.
>
> GEOBJECT TASKS/POLEXIS TO-DO's
>
>
> OPEN: Document that Canvases should accept Geobjects from other factories!
> Document a possible implementation architecture that would easily allow
> this.
>
> OPEN: GeoIcon& GeoScaledImage- add the URL methods?? (see the group
> question on this issue).
>
> OPEN: GeobjectStyle.setGradientPoints() - clarify this - i think they need
> to be CoordinateSource objects, not 4 floats...Can someone tell the group
> what the four points are used for?
>
> OPEN: add GeoLabel.get/setLabelColor()
>
> OPEN: add String[] getSupportedProjections() to Map2DGeobjectCapabilities
>
> NEW: removeGeobjectListener fails if the same listener is added twice.
>
> DECIDED, but not implemented as yet: Add helper ZOrder methods -
> getOpaqueOverlayZOrder(), etc. (Use integers, but go to MAX_INT...ask the
> group about using integers vs. floats or doubles).
>
> DONE: GeoEvents wrap AWT events (or was Robert gonna do this one?)
>
> DONE: Geobject.addToCanvas() and Geobject.addByAnimation()
>
> DONE: add GeobjectStyle.get/setZOrder(int zOrder)
>
> DONE: remove the setCenter(coord, controller) calls from Canvas, and
> document that the canvas/controller dance is open and unspecified.
>
> DONE: GeobjectListener - no Key events
>
> DONE: OOPS! There is still an org.geobject.GeobjectEvent...remove this
> class from sourceforge
>
> ______________________________________________________
>
> I THINK THESE WERE DECIDED ON (my bad if not!!):
>
> DONE: Geobject.setGeobjectStyle(newStyle) will do a COPY ON SET, not just
> set the internal style pointer to point to the passed in style.
>
> DONE: Remove recalculate() and repaint(), and add
> Geobject.fireGeobjectChanged(GeobjectEvent) ...or should it take a
> GeobjectChangedEvent?
>
>
> DONE: GeobjectManager.getGeobjectFactory(String calssname) {
> Class factoryClass = Class.forName(classname);
> GeobjectFactory factory = hashMap.get(factoryClass);
> if (factory == null) {
> factory = createFactory();
> hashMap.put(factoryClass, factory);
> }
> return factory;
> }
>
> DONE: add GeoCanvas.dispose()
>
> DONE (not added): add GeobjectManager.releaseFactory(Factory)
>
> DONE: add Canvas.get/setImplHint()
>
>
|
|
From: Argatides, P. <par...@no...> - 2002-11-21 17:10:05
|
No problem with this. Remove it. -Paris -----Original Message----- From: jesse crossley [mailto:cro...@po...] Sent: Wednesday, November 20, 2002 2:49 PM To: geo...@li... Subject: [Geobject-core] GeoKeyEvent & GeoMouseEvent i'm guessing this is a mistake i made at some point: in GeoKeyEvent, we have a getKeyEvent method and in GeoMouseEvent we have both getMouseEvent and setMouseEvent methods. so now i wonder, which is right? does it make sense to change a GeoMouseEvent's mouseEvent? i'm impling the events right now, and it seems that you would pass the java event into the GeoEvent's constructor. my vote is to remove the setMouseEvent method from GeoMouseEvent. jdc ------------------------------------------------------- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html _______________________________________________ Geobject-core mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geobject-core |
|
From: Rich K. <ka...@po...> - 2002-11-21 01:01:13
|
Do that, and if someone complains, we'll know what needs to be discussed and why. Thanks, Rich -- =20 Rich Kadel Chief Technology Officer Polexis, Inc. Direct: 619-542-7213 Fax: 619-542-8675 http://www.polexis.com/ transforming data into knowledge -----Original Message----- From: Jesse Crossley=20 Sent: Wednesday, November 20, 2002 2:49 PM To: geo...@li... Subject: [Geobject-core] GeoKeyEvent & GeoMouseEvent i'm guessing this is a mistake i made at some point: in GeoKeyEvent, we have a getKeyEvent method and in GeoMouseEvent we have both getMouseEvent and setMouseEvent methods. so now i wonder, which is right? does it make sense to change a GeoMouseEvent's mouseEvent? i'm impling the events right now, and it seems that you would pass the java event into the GeoEvent's constructor. my vote is to remove the setMouseEvent method from GeoMouseEvent. jdc ------------------------------------------------------- This sf.net email is sponsored by:=20 Battle your brains against the best in the Thawte Crypto=20 Challenge. Be the first to crack the code - register now:=20 http://www.gothawte.com/rd521.html _______________________________________________ Geobject-core mailing list Geo...@li... https://lists.sourceforge.net/lists/listinfo/geobject-core |
|
From: jesse c. <cro...@po...> - 2002-11-20 23:27:52
|
we still have createStyle methods on GeobjectFactory and GeobjectManager but we don't have Geobject.setStyle() anymore, so is there a need for standalone Style objects? i can still see the value of this method, because we can always getStyle().setPropertiesFrom(my_new_and_unattached_style) and that's what i'm about to do for some pooled objects i hafta deal with (when they are returned, we previously would setStyle(null) but i canna do that anymore). but it seems to me that this functionality could also be contained within a Style.reset() method (or something similar, you get the idea). any thoughts? i've got no problem with pursuing the aforementioned solution, but if we can make Geobject use simpler, than it will have a better chance at acceptance. jdc |
1 message has been excluded from this view by a project administrator.
