Maybe an option could be added to OJ to refuse, or at least warn, if one tries to add a different kind of geometry to an existing layer. Suppose you add to OJ a layer full of linestring and then try to draw a point on it. OJ could immediately stop or warn you. Even if the layer was completely empty, the first geometry added should impose the type of the subsequent ones. This would work even with OJ not knowing where the layer came from.
Bye Paolo Rizzi > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto > di Sunburned > Surveyor > Inviato: martedì 18 settembre 2007 21.21 > A: JUMP Users Discussion > Oggetto: Re: [jump-users] OpenJUMP-PostGIS integration problem > > > 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 <[EMAIL PROTECTED]> 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 > > > _______________________________________________ > jump-users mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jump-users > _______________________________________________ jump-users mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jump-users
