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
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 sst...@geo.uzh.ch wrote:
Kevin Neufeld wrote:
No, the ability to
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
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
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
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
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
first
. 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 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
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 kneuf...@refractions.netwrote:
Hi Stefan,
You're right, I once did have write access to the old JUMP ... that was
a long time ago. I'm
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 becker.la...@gmail.com wrote:
Hi Kevin,
I had a look at your patch. It looks
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
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
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
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.
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
16 matches
Mail list logo
