My 2c worth on this is that the way to add this functionality would be
to add a concept of Geometry Type Constraint to Layers. This constraint
would be settable either by a UI or when a layer is read from a
datasource which is known to only provide homogeneous geometry. This
feature would be part of the Layer API, and it would be up to any code
creating layers to set this information appropriately, and up to tools
modifying the layer to obey the constraint (although it would be
possible to wrapper the Layer feature collection to prevent illegal
geometry types from being entered).
If this was done, it should be made easy to drop the constraints from a
layer, to avoid user frustration.
The trick would be knowing when data sources carry implicit type
constraints. Shapefiles are fairly obvious, I guess. PostGIS layers are
probably more difficult to tell this (is there even a standard way of
doing this?)
Another feature along this line would be to set the Precision Model
(snapping grid) for layers independently, so that all data and
operations carried out on a given layer would be carried out in the
Precision Model. This is more complex and wide-ranging to implement,
however.
Giuseppe Falcone wrote:
Hi
thanks for the response.
The Sunburned Surveyor says: "This is because JUMP really doesn't know
anything about where a layer comes from in the current implementation".
OK. But openJUMP knows the feature type that this layer contains and could
force some constraint on users' operations to avoid errors (constraint that
the user could remove, if he wants)
On QGIS (another open-source GIS) if I add a layer that contains linear
feature and I want modify it, the 'add point' and 'add line' command are
disabled.
On Intergraph Geomedia (a commercial GIS) I couldn't draw linear features on
an areal layer, because the relative command are disabled.
The same thing occurs on ESRI Arcview (another commercial GIS).
Of course, I don't says that the openJUMP behaviour is wrong and my assertion
is correct, but I find almost strange that other GIS product (either
commercial or open-source) behave in different way from openJUMP.
Giuseppe
Peppe,
I'm not a PostGIS user, so be patient with me.
You wrote: "This (for me) is the question. I think that a user
couldn't draw on a layer
imported from an existing postGIS table a geometry of a different type
because he should have an error if updated the table with the new features.
Should exist the way to enforce that constraint on a openJUMP layer."
This is because JUMP really doesn't know anything about where a layer
comes from in the current implementation. I was working on some code a
while back that associated layers with "datasources". This code, would
for example, allow you to select a datasource representing a database
and then update all the layers associated with the database.
The code was never finished because of problems I had with the project
sponsor.
In summary, I think the only way to do what you are talking about is
to have a tool that associates layers with their data source.
Peppe wrote: "Also, when I create a layer on openJUMP, draw some
features on it and then
save it on postgis table, the table created has the geometry field of type
'GEOMETRY' and only two constraint on this field:
1. constraint on SRID
2. constraint on dims of geometry
The data are saved successfully on this postGIS table."
I think you are pointing out an inconsistency between the shp2pgsql
utility and the PostGIS plug-ins for OpenJUMP. I don't know that their
is a way to fix this without rewriting the PostGIS plug-in code, and I
don't know that the plug-in way is wrong and the other way is
"correct". Maybe they are just different ways of doing the same thing?
(It would be nice if they were consistent.)
The Sunburned Surveyor
On 9/18/07, Giuseppe Falcone <g.falcone at tecnologieavanzate.it> wrote:
Hi Stefan,
first of all, excuse for my poor english and thanks for the response.
I have make some new tests on PostGIS-OpenJUMP integration and I get this
results:
I create a postGIS table from some shapefiles using the postGIS loader
shp2pgsql. That script create a table with a field named 'gid' (datatype
'serial') on which is created the primary key of the table.
On the field that contains the geometry (named 'the_geom') are created,
automatically, three constraint:
1. constraint on SRID
2. constraint on dims of geometry
3. constraint on type of geometry
If I created a layer on openJUMP that contains only geometry of the type
equal
that on postGIS table I can import them successfully in the table (in
insert
and in overwrite mode).
This (for me) is the question. I think that a user couldn't draw on a layer
imported from an existing postGIS table a geometry of a different type
because he should have an error if updated the table with the new features.
Should exist the way to enforce that constraint on a openJUMP layer.
Also, when I create a layer on openJUMP, draw some features on it and then
save it on postgis table, the table created has the geometry field of type
'GEOMETRY' and only two constraint on this field:
1. constraint on SRID
2. constraint on dims of geometry
The data are saved successfully on this postGIS table.
Another question: there's a way to draw features M
(MULTILINESTRING,MULTIPOLYGON, ..) on a openJUMP Layer?
Thanks for the interest.
Giuseppe
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jump-users mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jump-users
