Hi,
Is the insert fired automatically when a new feature is ready? Just
wondering what happens if saving is manual and user has been panning
around so that the new feature is outside the current viewport. What
about if new feature is originally created outside the current bounding
box by inserting
I was just curious. Exposing this functionality to the user through
the GUI might create problems I haven't thought of.
Thanks for the clarification Kevin.
The Sunburned Surveyor
On Wed, Sep 8, 2010 at 4:44 PM, Stefan Steiniger wrote:
> Kevin Neufeld wrote:
>> No, the ability to specify readonl
Kevin Neufeld wrote:
> No, the ability to specify readonly is currently only available
> programatically. My use case was that I wanted to prevent a user to
> making certain changes to a feature collection. I hadn't considered
> that a user may want to add this restriction themselves through a
No, the ability to specify readonly is currently only available
programatically. My use case was that I wanted to prevent a user to
making certain changes to a feature collection. I hadn't considered
that a user may want to add this restriction themselves through a user
interface. Do you thi
Kevin,
This is probably a dumb question, but is there a way to tell OpenJUMP
that a feature attribute is not editable for a layer through the user
interface?
I was trying to see how I could do this in the dialog that lets you
edit a layer schema in a build from SVN, but couldn't see it. Is this
f
I'm programmatically invoking a refresh on the layer - any data
currently in the bounding box of the viewport is reloaded from the
datastore ... which includes the newly inserted feature. I suppose I
could be smarter about this and reload all features whose bounding boxes
match the bounding bo
Hi,
One further question: How are you going to get the ID of the newly inserted
feature back to OpenJUMP side?
-Jukka-
-Original Message-
From: Kevin Neufeld [mailto:kneuf...@refractions.net]
Sent: Mon 6.9.2010 9:35
To: OpenJump develop and use
Subject: Re: [JPP-Devel] wishlist
Hi
Hi Jukka,
Yes, inserts are more tricky than other modification types. However,
IMHO, a properly modeled database will include sequence generators,
rules, or triggers on database tables enforcing the primary key attribute.
My first iteration through this will be to simply target the most common
. The better way is to use triggers but it goes more
complicated.
-Jukka Rahkonen-
-Alkuperäinen viesti-
Lähettäjä: Kevin Neufeld [mailto:kneuf...@refractions.net]
Lähetetty: la 4.9.2010 6:22
Vastaanottaja: OpenJump develop and use
Aihe: Re: [JPP-Devel] wishlist
Hi Michael, good
Hi Kevin,
> Yes, I'm in process of implementing some datastore plugins that will
> permit the dynamic reading and writing to a database. I wrote a quick
> hacky plugin many years ago that does this for PostGIS. I want to
> release this to the community because it seems quite useful, but I'm
> f
Hi Michael, good thoughts.
Yes, I'm in process of implementing some datastore plugins that will
permit the dynamic reading and writing to a database. I wrote a quick
hacky plugin many years ago that does this for PostGIS. I want to
release this to the community because it seems quite useful,
Hi,
I just had a look at your patch which seems good to me.
I have some questions about it :
1 - Do you plan to improve database connection plugins to prevent
modifications on some kinds of database attributes ?
2 - Do you just want to prevent attribute writing throught the LayerTable ?
Beca
I'll give it a spin in the nightly build tomorrow, but Larry is pretty
reliable. :]
Glad you got access with no problems. Welcome to the team. :]
SS
On Thu, Sep 2, 2010 at 8:59 AM, Kevin Neufeld wrote:
> Patch has been committed at r2034, no problems. Let me know if anyone
> has issues with t
Patch has been committed at r2034, no problems. Let me know if anyone
has issues with the addition.
Thanx all,
-- Kevin
On 9/2/2010 8:29 AM, Sunburned Surveyor wrote:
> Kevin,
>
> You've been added to the Jump Pilot Project on Sourceforge and now
> have write access to the SVN. You can commit
Kevin,
If Stefan hasn't beat me to it, give me your Sourceforge user name and
I'll get you write access to the SVN.
Thanks for testing the patch Larry.
Landon
On Thu, Sep 2, 2010 at 6:37 AM, Larry Becker wrote:
> Hi Kevin,
>
> I had a look at your patch. It looks pretty good to me. Nice
Hi Kevin,
I had a look at your patch. It looks pretty good to me. Nice addition!
regards,
Larry
On Thu, Sep 2, 2010 at 12:31 AM, Kevin Neufeld wrote:
> Hi Stefan,
>
> You're right, I once did have write access to the old JUMP ... that was
> a long time ago. I'm surprised you remembered :
Hi Stefan,
You're right, I once did have write access to the old JUMP ... that was
a long time ago. I'm surprised you remembered :) Sure, if you're
willing, I wouldn't mind having access again. I'm not planning on any
major core contributions, but in my spare time as I'm working on various
Hei Kevin,
do you want SVN write access?
so this way we do not need to sent patches around, and I think you did
already a couple of contributions (on the good old JUMP-cvs before it
was gone. So there would be no concern about your skills ;)
However, if core features are concerned we usually ha
That is the thing with opensource development, eh? :) Development
resources are always tight.
I just added a patch for review to the feature tracker for my primary issue.
http://sourceforge.net/tracker/index.php?func=detail&aid=3057748&group_id=118054&atid=679909
The patch
- adds a readonly att
Hi Kevin
All your propositions seem reasonnable and valuable for OpenJUMP.
As Stefan said, the main problem is development resources.
I cannot evaluate precisely the work to do without a deeper look, but it
concerns core classes and will need caution and tests.
Are you volonteer to develop the
Ah, great, thanx Stefan. I'll add the requests there so others can
comment/poke holes/massage/scrap the ideas.
Yeah, OJ is by far my preferred desktop GIS client. The fact that OJ is
so tightly coupled with JTS (which is the backbone of PostGIS through
GEOS) makes it great to work with.
Ch
Hei Kevin,
thanks for you thoughts. Sounds all pretty reasonable to me - the only
issue is "developer time" ;)
In general we have at SourceForge the Bug Tracker and Feature-Request
Tracker. So that would be the place to add your 3 wishes:
http://sourceforge.net/projects/jump-pilot/support
We
Stefan mentioned that there isn't a road map for OJ, but is there a
place to jot down improvement ideas?
Here are a couple on my wishlist:
1) The ability to specify which columns are editable in an layer's
attribute table. Right now, the FID and geometry column are hard-coded
as being the o
23 matches
Mail list logo
