Hi Martin and all,
I must admit I have trouble following the discussion on this list with
this amount of activity going on. ;-)
Martin Davis schrieb:
> [snip]
>
> More generally, this is all moving in the direction of supporting a full
> GML-like data model, where Features can contain Featu
Hello Craig, SS,
"A. Craig West" <[EMAIL PROTECTED]>, [20070604 - 22:22:16]
> Normally, the head is the unstable code, and any changes which have
> been tested get merged to the stable branch...
Yes, that was my intention to tell as well. I strongly suggest to
fo
AD which gets branched into
> > release-branches which can be kept separately. I am involved in several
> > OS software development where this structure is quite common.
> >
> > To introduce this now would lead into adding a branch (release_1.2) of
> > the current HEAD. Pe
Martin wrote: "...Actually, my
original concept for JUMP was that there would be a Catalog concept,
with a UI which showed all the spatial tables which were loaded and
exposed as Layers in Task map views. Non-spatial tables would have just
shown up in the Catalog window. Ideally you could drag'n'
Inkscape: http://www.inkscape.org/
Scribus: http://www.scribus.net/
OpenJUMP Basics Tutorial:
http://superb-west.dl.sourceforge.net/sourceforge/jump-pilot/OpenJUMP1.0.1_Tutorial_englishBeta.pdf
On 6/4/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> Giuseppe,
>
> We should definitely work to
Giuseppe,
We should definitely work together on the OpenJUMP documentation. I
can help you with the English translations of your work.
Have you ever used the open source desktop publishing software
Scribus? How about the vector program Inkscape? Those are two of the
tools that I am using to write
There is almost too much good stuff going on around here to keep up with. :]
Paul wrote: "I agree if the open source GIS community can agree on a
single in memory Java representation for geographic features that
would make all the tools more interoperable."
You should definitely get more involved
The reason I was thinking of Object type for Ids is that then you could
use a Long, Integer or String for the feature ID depending on the type
of data. I normally use Long but some models may use String based
globally unique ids, I wouldn't want to use String for numeric fields
all the time.
O
Stefan,
POJO is a Plain Old Java Object so when you see that it means the
property value can be any Java object, we don't have to know how to
handle it but some models may require the data to be persevered.
A feature without a schema is basically just a Map of property names to
values, rather
Hi Paul,
1. Do you really need Object type for ids (I think ids are Strings in
GeoTools - don't know if there is performance penality compared to int
ids, or some cases where a genaral Object type is needed)
2/3. If I can remember, GeoTools complex feature model fulfill 2 and 3
requirements, an
hei..
i did not read all the stuff before until now... but..
your suggestions are nice..
but if i think what all need to be changed (especially in terms of
avoiding errors).. i don't know?
but maybe it is more simple than i thought if one can simply add some
feature properties such as Attribtut
Sunburned Surveyor wrote:
> I still think you could encapsulate this functionality in a plug-in or
> set of plug-ins. This might not be the best way to go long term, but
> it could let us test out how things would work without messing with
> the core.
>
> For example, I wouldn't even mess with th
Ok, sounds cool.
One slight clarification/comment - I don't think you want to "switch on
the fly the renderers in the registry". The whole idea behind the
Registry is that it is a pretty much static container of components (or
Strategy objects). Registry items can be added (by plugins or on
I don't have time to look at it closely right now, but it sounds like
a logical simplification. I hate that temp array too.
regards,
Larry
On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Hi Sascha;
>
> Sounds interesting.
> Please, let me some more time to have a closer look and see how
I agree if the open source GIS community can agree on a single in
memory Java representation for geographic features that would make all
the tools more interoperable. Right now I'm using my own schema and
feature model but would prefer not to maintain that in the future. Here
are the requiremen
I thought I would start a new thread so we could split this apart from
the discussion that Paul and Martin were having about the FeatureInfo
tool.
When I suggested that support for non-spatial features could be
included in a plug-in Martin wrote: "I had similar thoughts a while
back. In fact, the
Good point, Michael, I should have mentioned the GeoTools Feature model
as a possible direction as well. Definitely it would be a good thing to
evolve in their direction.
I'm not sure how stable or baked the GT Feature model design is, but as
it happens I sit right next to one of the chief GT
Yes, definitely that would be cool. This would be equivalent to a
defining a view in an RDBMS.
Michaël Michaud wrote:
> Sounds good,
>
> And what about having a way to join a spatial layer in OJ to a
> non-spatial db table or view, and to see the whole result as one flat
> layer in OJ...
>
> m
Hi Giuseppe,
There is some JUMP's technical and user documentation on the original
JUMP's site (a bit old but very nice),
and a more recent tutorial for OpenJUMP you can download from
http://sourceforge.net/project/showfiles.php?group_id=118054
This OpenJUMP tutorial has been translated from ge
Martin,
You wrote: "Your suggestions for enhancing the FeatureInfoTable view
all sound good to me, Paul. It's a nice idea to have different
Geometry text
renderers. I might even go further and define a simple framework for
GeometryTextRenders, which could have different instantiations added in
t
Hi Paul,
Your feature info frame looks nice.
The discussion you have with Martin is very interesting and very
important as it is about JUMP's feature model.
I just want to mention other discussions we had on this list about the
interest to write bridges between JUMP's feature model and GeoTool's
am involved in several
> OS software development where this structure is quite common.
>
> To introduce this now would lead into adding a branch (release_1.2) of
> the current HEAD. Perhaps it is not so difficult to set up nightly
> builds from both HEAD and release-branch?
>
> Ju
Sounds good,
And what about having a way to join a spatial layer in OJ to a
non-spatial db table or view, and to see the whole result as one flat
layer in OJ...
my two cents
Michaël
P.Rizzi Ag.Mobilità Ambiente a écrit :
>Support for non-spatial DB tables would be a _great_ thing!!!
>You can
Hi Martin,
I'm just working on a concept of a HtmlRenderer that will take an
object and convert it to HTML for display in Swing HTML widgets. There
will then be a HtmlRendererRegistry that will map from a Java Class to
a renderer. When displayign features you would use the registry to get
a re
All good points, Paolo.
P.Rizzi Ag.Mobilità Ambiente wrote:
> Support for non-spatial DB tables would be a _great_ thing!!!
> You can do lots of thing with them (use attributes to theming other layers),
> or you can even create geometries on the fly using some of their attributes
> plus some Bea
Agreed, I realize that you have to do some namespace mangling. It all
comes down to how much coding you want to do to support your need.
Supporting attributes which are lists of values is another story... It
may be fine for your use case to simply display these as a String, but
it would be n
Your suggestions for enhancing the FeatureInfoTable view all sound good
to me, Paul. It's a nice idea to have different Geometry text
renderers. I might even go further and define a simple framework for
GeometryTextRenders, which could have different instantiations added in
the Registry. The
ture is quite common.
To introduce this now would lead into adding a branch (release_1.2) of
the current HEAD. Perhaps it is not so difficult to set up nightly
builds from both HEAD and release-branch?
Just my 0.02 ¢
Stephan
"Sunburned Surveyor" <[EMAIL PROTECTED]>,
[
I took some time to read over the chapter in the CVS manual on
branching and merging. I have some comments now on the method I think
we should use for the development branch in the OpenJUMP CVS.
I believe that we should use the method described in Michael's option
#3 in this thread. This is basica
Stefan,
Ignore my comment about SkyJump plugin's I was just using an older
version of JUMP, now with the 1.2 pre release I see they are already there.
Cheers,
Paul
Stefan Steiniger wrote:
I did a one-to-one copy if i remember correctly (since i have no
experiences with databases i would not
Paul,
If this is a question of modelling a single complex attribute which is
in 1-1 relation with the parent feature, why don't you just present the
attributes as a set of attributes on the parent feature? Granted this
increases the column namespace a bit, but it doesn't require any
additiona
Hi Martin,
I've never been a fan of doing automated flattening of hierarchical data
models as you either have to include a prefix on the attribute names or
some other form of name mangling to avoid name collisions, also it
doesn't cope well if you have parts of it that are optional or contain
Hello OpenJUMP users,
the development of a WFSPlugin has started in early april and a first
version was given to the community recently.
Now with this release we have have fullfilled the roadmap within
this project and release the WFSPlugin as 1.0.0.
There are lots of bugfixes and some new featu
Support for non-spatial DB tables would be a _great_ thing!!!
You can do lots of thing with them (use attributes to theming other layers),
or you can even create geometries on the fly using some of their attributes
plus some BeanShell code, for example.
Or they can be used to edit geometric layers
Hi,
Michaël Michaud schrieb:
> Hi,
>
> Thanks Stefan,
> Is there a way to use sourceforge cvs log to help completing the
> changelog file you just added ?
There are several tools for this out there. cvs2cl.pl [1] e.g
is working fine.
But ones again: Writing a ChangeLog this way is only for
the
35 matches
Mail list logo
