Re: [postgis-users] PostGIS 2.1 CREATE EXTENSION vs Loading postgis.sql and spatial_ref_sys.sql

[Puthick Hok]

BladeOfLight16 wrote:
On Tue, Feb 3, 2015 at 11:41 PM, Puthick Hok > wrote:


I use Perl DBI to connect to Postgresql. If I create the postgis
database using 'CREATE EXTENSION' method, Perl DBI returns
'layer_id' as the primary key of my layer table. If I create the
postgis database using the old incompatible way of loading
postgis.sql and spatial_ref_sys.sql, Perl DBI returns 'id' as it
is named as the primary key of my layer table.


That doesn't make sense. I'm pretty sure that neither CREATE EXTENSION 
nor running postgis.sql and spatial_ref_sys.sql would affect the 
primary key of an existing table. Most likely, you're running some 
other SQL of your own, and you have something weird going on in that. 
How are you creating your "layer table"?



___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users


I have double checked my code 'layer_id' is coming straight from calling 
$dbh->primary_key( undef, undef, 'layer');
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] PostGIS 2.1 CREATE EXTENSION vs Loading postgis.sql and spatial_ref_sys.sql

[Puthick Hok]

BladeOfLight16 wrote:
On Tue, Feb 3, 2015 at 11:41 PM, Puthick Hok > wrote:


I use Perl DBI to connect to Postgresql. If I create the postgis
database using 'CREATE EXTENSION' method, Perl DBI returns
'layer_id' as the primary key of my layer table. If I create the
postgis database using the old incompatible way of loading
postgis.sql and spatial_ref_sys.sql, Perl DBI returns 'id' as it
is named as the primary key of my layer table.


That doesn't make sense. I'm pretty sure that neither CREATE EXTENSION 
nor running postgis.sql and spatial_ref_sys.sql would affect the 
primary key of an existing table. Most likely, you're running some 
other SQL of your own, and you have something weird going on in that. 
How are you creating your "layer table"?



___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

My create table and index are:

CREATE TABLE layer (
   id integer NOT NULL,
   parent bigint NOT NULL,
   name character varying(100) NOT NULL,
   alias character varying(100),
   layertype character varying(30) DEFAULT 'layer'::character varying 
NOT NULL,

   layermetadata text,
   iseditable smallint DEFAULT 1 NOT NULL,
   createuser bigint DEFAULT 0 NOT NULL,
   createtime timestamp without time zone NOT NULL,
   lastupdateuser bigint NOT NULL,
   lastupdatetime timestamp without time zone NOT NULL,
   srid bigint DEFAULT 4326 NOT NULL,
   geometrytype character varying(30),
   description character varying(254),
   owngroupid bigint NOT NULL,
   accessgroupid bigint DEFAULT 0 NOT NULL,
   owngroupperm smallint NOT NULL,
   accessgroupperm smallint DEFAULT 0 NOT NULL,
   otherperm smallint DEFAULT 0 NOT NULL
);

CREATE SEQUENCE layer_id_seq
   START WITH 1
   INCREMENT BY 1
   NO MAXVALUE
   NO MINVALUE
   CACHE 1;


ALTER TABLE public.layer_id_seq OWNER TO auser;

ALTER SEQUENCE layer_id_seq OWNED BY layer.id;

SELECT pg_catalog.setval('layer_id_seq', 1, false);

ALTER TABLE ONLY layer
   ADD CONSTRAINT layer_pkey PRIMARY KEY (id);
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] PostGIS 2.1 CREATE EXTENSION vs Loading postgis.sql and spatial_ref_sys.sql

[BladeOfLight16]

On Tue, Feb 3, 2015 at 11:41 PM, Puthick Hok  wrote:

>   I use Perl DBI to connect to Postgresql. If I create the postgis
> database using 'CREATE EXTENSION' method, Perl DBI returns 'layer_id' as
> the primary key of my layer table. If I create the postgis database using
> the old incompatible way of loading postgis.sql and spatial_ref_sys.sql,
> Perl DBI returns 'id' as it is named as the primary key of my layer table.
>

That doesn't make sense. I'm pretty sure that neither CREATE EXTENSION nor
running postgis.sql and spatial_ref_sys.sql would affect the primary key of
an existing table. Most likely, you're running some other SQL of your own,
and you have something weird going on in that. How are you creating your
"layer table"?
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

[postgis-users] PostGIS 2.1 CREATE EXTENSION vs Loading postgis.sql and spatial_ref_sys.sql

[Puthick Hok]

Hi,

I was given a schema whose tables contain primary key fields named just 
'id'. For example, layer table has 'id' field as it primary key and 
'name' as a normal field. I already know that these two names are not 
good name because they are reserved words used in many places like they 
break XML, for example.


I use Perl DBI to connect to Postgresql. If I create the postgis 
database using 'CREATE EXTENSION' method, Perl DBI returns 'layer_id' as 
the primary key of my layer table. If I create the postgis database 
using the old incompatible way of loading postgis.sql and 
spatial_ref_sys.sql, Perl DBI returns 'id' as it is named as the primary 
key of my layer table.


Can anyone explain the details? My postgresql is 9.3.5 and postgis is 
2.1. I need an excuse for my broken code just because the database is 
created using a different method.


Thanks,
Puthick
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] Convert from Lat/Long point to postGIS geometry

[Brent Wood]

I recommend you use QGIS to visualise your Postgis data & ensure it is correct 
before using Geoserver; QGIS & Postgis work very well together.
Postgis can help with the automatic populating of the data. You can create an 
on insert (or update) trigger in Postgres which will populate the missing 
column(s) whenever a record is inserted (or updated). A simple scrupt that does 
this is below - just a series of SQL's to illustrate this. Note that if you 
update a record (change x or y values) then the point will be in the wrong 
place, it needs updating as well. Ideally you should create an update & insert 
before function to replace the insert/update with a new one doing the full 
job... but this will hopefully illustrate how you might go about this.
If all your inserts/updates are done programatically rather than manually, then 
you may be able to modify the program to do this without using the db to 
automate it.
Cheers
  Brent


#! /bin/bash
# script to create database, install postgis, and create:
#   a table with a geometry column & x,y columns
#   a trigger function to update the table geometry column,
#    populating null geometries with a geometry made from coords 
#   a trigger invoking the function on update
# run a couple of inserts to test it works
# look at the result

dropdb test
createdb test
psql -d test -c "create extension postgis;"
psql -d test -c "create table test_trigger 
   (id    serial primary key,
    x decimal(7,4),
    y decimal(7,4),
    geom  geometry(point, 4326));"

psql -d test -c "CREATE OR REPLACE Function update_geom() RETURNS TRIGGER AS 
 \$\$
 BEGIN 
   UPDATE test_trigger SET geom = 
ST_SetSRID(ST_Makepoint(x,y),4326) where geom isnull;
   RETURN null;
 END;
 \$\$ 
 LANGUAGE 'plpgsql';"

psql -d test -c "CREATE TRIGGER geom_trigger AFTER INSERT ON test_trigger FOR 
EACH ROW EXECUTE PROCEDURE update_geom();"

psql -d test -c "insert into test_trigger (x, y) values (179.0, -45.0);"
psql -d test -c "insert into test_trigger (x, y) values (179.5, -45.3);"
psql -d test -c "select id, x, y, ST_AsText(geom) from test_trigger;"



The result of running this is:
CREATE EXTENSION
CREATE TABLE
CREATE FUNCTION
CREATE TRIGGER
INSERT 0 1
INSERT 0 1
 id |    x |    y | st_astext  
+--+--+
  1 | 179. | -45. | POINT(179 -45)
  2 | 179.5000 | -45.3000 | POINT(179.5 -45.3)
(2 rows)


  From: KhunSanAung 
 To: Brent Wood  
Cc: "postgis-users@lists.osgeo.org"  
 Sent: Tuesday, February 3, 2015 9:08 PM
 Subject: Re: [postgis-users] Convert from Lat/Long point to postGIS geometry
   
Hi Brent Wood,
Many thanks, it works.UPDATE public.town SET geom = 
ST_SetSRID(ST_MakePoint(longitude, latitude), 4326);

I am using postGIS to store the data and using GeoServer for publishing the 
data to maps.
I'm thinking to use the GeoExplorer (from OpenGeo Suite) for digitizing and 
collecting the location information.When using GeoExplorer, the geometry 
information is automatically stored to the geom field of the table and the use 
have to fill all the attribute again.
But I already have the full list in a postGIS table.How can I make my 
application in such a way that user just need to select from the list and 
digitizing the location only. No need to enter the attribute again.
Many thanks for any  idea.
Best regards




On Tue, Feb 3, 2015 at 10:50 AM, Brent Wood  wrote:

Hi.
Try something like:

update  set  = ST_SetSRID(ST_MakePoint(Longitude, 
Latitude),4326);
Essentially create a point geometry from your numeric values, with the 
ST_MakePoint() function, the inform Postgis it is a standard lat/long CS 
(EPSG:4326 - which you should have specified when you created the column), & 
update the table with these values for each row. Make sure you use your table & 
column names
What mapping/GIS program are you using?

Cheers,
  Brent Wood

  From: KhunSanAung 
 To: postgis-users@lists.osgeo.org 
 Sent: Tuesday, February 3, 2015 5:11 PM
 Subject: [postgis-users] Convert from Lat/Long point to postGIS geometry
   
Hi All,
I have one table (Town info) in postgres without Geometry field.I have Latitude 
and Longitude information for those points data separately (collecting & 
filling).

I created the postGIS extension and add the Geometry field in the above 
postgres table.Now, I'd like to add the location information into the postGIS 
geometry field so that I can immediately view those points on the map. 
How can I convert the Latitude/Longitude value into postGIS geometry value?
Thank you very much in advance.
-- 
Have a nice day!
--
Mr. Khun San Aung
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

   



-- 
Have a nice day!
--
Mr

[postgis-users] Getting TopologyExections when trying to node linestrings to create an overlay

[BladeOfLight16]

I'm trying to create a polygon overlay. The basic process is relatively
simple: 1) Get the boundaries 2) Union the boundaries to node the
linestrings 3) Polygonize the noded outlines 4) Filter out holes using a
contains or intersects test. The problem I'm running into is that I'm
getting "GEOSUnaryUnion: TopologyException: found non-noded intersection
between LINESTRING" errors from ST_Union.

I've taken the liberty of creating a script that will set up a database to
reproduce what I'm seeing. I've gzipped it in the interest of size, since
it's got a fairly sizable set of polygons. Let me know if this delivery
method is a problem; I'll be happy to use other means. You can find it
here:
https://drive.google.com/file/d/0B_6I7kRgE8teVUpha2Q4ZlNDMWs/view?usp=sharing.
(I originally tried to attach it, but the PostGIS mailing list rejected
it.) The contents are a plain SQL file. It won't create a database for you,
but it will create the PostGIS extension IF NOT EXISTS. Specifically for
this problem, it creates and populates this table:

CREATE TABLE error_generating_polygons (
geom_set_id SERIAL PRIMARY KEY,
outer_boundary geometry NOT NULL,
polygons geometry[] NOT NULL,
error_code text NOT NULL,
error_message text NOT NULL
);

It's a little weird, so I think I should provide some explanation. The
primary key is just a surrogate. The outer_boundary can be ignored for the
purposes of this error; it's there for me for that filtering out holes and
chaff after I get the raw overlay back. The polygons column is the most
interesting; it contains a set of polygons that will reproduce this error.
(I'll get into why I use an array in a minute.) The error_code and
error_message are the values of SQLSTATE and SQLERRM I get when noding the
boundaries; I've included them so that anyone can compare if they get
different results.

The reason I have an array of polygons is that this was the simplest method
of providing a large group of polygons. The data you're seeing here is not
sample data I've made up. This is real world data provided to me by a
client, who has produced them primarily through a mixture of GPS, manual
processing, and probably some more or less "automated" processing. In
short, it's pretty messy, and these are the actual polygons I need to
overlay. As for why I'm giving you these big groups instead of breaking
things down into smaller chunks, I did try that, at least somewhat. I found
that if I broke this up into pairs of polygons, I could only reproduce the
error with a *single* pair out of thousands of combinations. So sorry for
the shear number of polygons here, but apparently, the errors come at least
partly from some cumulative effect.

I have verified that every polygon in there is a valid one:

SELECT geom_set_id, ST_IsValidDetail(geom)
FROM (SELECT geom_set_id, UNNEST(polygons) geom
  FROM error_generating_polygons
 ) x
WHERE NOT ST_IsValid(geom);

That query gives me an empty set, plus I do plenty of checking before
letting a geometry get into the system.

Now, to get down to business. Here's the query you can run to see errors:

DO $$
DECLARE problem_row error_generating_polygons%ROWTYPE;
BEGIN
  FOR problem_row IN (SELECT * FROM error_generating_polygons) LOOP
BEGIN
  PERFORM ST_Union(ST_Boundary(geom))
  FROM UNNEST(problem_row.polygons) p (geom);
  RAISE NOTICE 'geom_set_id % succeeded', problem_row.geom_set_id;
EXCEPTION
  WHEN OTHERS THEN
RAISE NOTICE 'Error for geom_set_id % (Code %): %',
problem_row.geom_set_id, SQLSTATE, SQLERRM;
END;
  END LOOP;
END
$$;

I also tried a variant of this: I replaced ST_Bounrary(geom) with
ST_Boundary(ST_SnapToGrid(geom,
0.01)).

I tested on two separate installations of PostgreSQL/PostGIS. Believe it or
not, I'm getting different results from these. Here are the specs and
results for each one:

1) Runs on CentOS, installed from CentOS repositories (I believe. I need to
double check with IT to be 100% sure). Version Info:

PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-4), 64-bit
POSTGIS="2.1.4 r12966" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6
March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6"
LIBJSON="UNKNOWN" RASTER

Every row throws an error on this one. This is where the errors in the
table come from. Adding ST_SnapToGrid makes it error out on only one row.

This one is more similar to my production machine at present.

2) Runs on Debian, installed from PostgreSQL maintained repository. Version
info:

PostgreSQL 9.4.0 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.7.2-5) 4.7.2, 64-bit
POSTGIS="2.1.5 r13152" GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel. 4.7.1, 23
September 2009" GDAL="GDAL 1.9.0, released 2011/12/29" LIBXML="2.8.0"
LIBJSON="UNKNOWN" RASTER

This one errored out less; only about 1/3 of the rows error out. Adding
ST_SnapToGrid also makes it error out on only one row.


An oddity to note: the Debian install has a

Re: [postgis-users] English please

[Rémi Cura]

You are welcom
It wasn't a bug, so no ticket, so nothing to do ;-)
Cheers,
Rémi-C

~~~Français~
Pas de problème,
comme il ne s'agissait pas d'un bug, je n'ai pas créé de ticket, donc il
n'y a rien à faire.
Salutations,
Rémi-C

2015-02-03 14:53 GMT+01:00 Guillaume ARNAUD :

>  Thank you for your help. The example is exactly what I need.
> I apologize for speaking French to other users. If I again need help or if
> one day I can bring my own, I will try to do it in English.
> Good job for this function Remi and thank you again.
> How can i close this topic and note that my problem is solved?
> Cheers,
> Guillaume
>
> Le 03/02/2015 13:10, Rémi Cura a écrit :
>
>   /*french version at the end*/
>  Ok I think I found the problem :
>  your geometry are not simple, that is in postgis langage, there is no
> selfintersection.
>  Your lines have tone of selfintersection , which is forbiden (because
> GEOS does topological computation)!
>
>  So now of to fixe this : use this function
> 
> to transform your non-simple (multi)line into multiline where each line
> inside is simple.
>  You code becomes :
>
> SELECT objectid, nom, code
> , ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as
> offseted_linestring
> FROM web.trs_itineraire , st_Dump(rc_MakeSimple(shape)) as dmp
> WHERE code = '06-20B'
>
>  It execute successfully (now does it do what you expect, I don't know)
>  (tested on the data you shared, no translation, no snapping)
>  Cheers,
> Rémi-C
>
>   French version 
>
>  J'ai trouvé le problème je pense.
> En fait les géométries ne sont pas simple au sens de PostGIS, c'est à dire
> "qui ne s'autointersecte pas".
>  Cela est interdit et cause les erreurs de GEOS (qui fait du calcul
> topologique).
>
>  Maintenant la solution pour régler simplement le problème :
>  utiliser cette fonction
> 
> pour passer de (multi)lignes avec des autointersections à des multilignes
> dont chaque lignes composante ne s'autointersecte pas.
>
>  Du coup,
>  votre code devient :
> SELECT objectid, nom, code
> , ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as
> offseted_linestring
> FROM web.trs_itineraire , st_Dump(rc_MakeSimple(shape)) as dmp
> WHERE code = '06-20B'
>
>  La requete s'execute sans erreurs (après le résultat ne sera pas
> nécessairement ce que vous attendez, mais c'est une autre histoire).
>  (testé sur les données que vous avez partagées, sans translation ni
> snapping).
>
>  Salutations,
> Rémi-C
>
> 2015-02-03 9:12 GMT+01:00 Sandro Santilli :
>
>> On Sun, Feb 01, 2015 at 08:46:16PM +0100, Rémi Cura wrote:
>>
>> > We are coming closer to a GEOS or PostGIS bug.
>>
>> Please use the bug tracker for these, thanks.
>>
>> --strk;
>> ___
>> postgis-users mailing list
>> postgis-users@lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>
>
>
>
> ___
> postgis-users mailing 
> listpostgis-users@lists.osgeo.orghttp://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
>
> --
> Guillaume ARNAUD
> Cellule SIGD
> Direction de l'Informatique
> Conseil Général de Tarn-et-Garonne
>
>
>
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] English please

[Guillaume ARNAUD]

Thank you for your help. The example is exactly what I need.
I apologize for speaking French to other users. If I again need help or 
if one day I can bring my own, I will try to do it in English.

Good job for this function Remi and thank you again.
How can i close this topic and note that my problem is solved?
Cheers,
Guillaume

Le 03/02/2015 13:10, Rémi Cura a écrit :

/*french version at the end*/
Ok I think I found the problem :
your geometry are not simple, that is in postgis langage, there is no 
selfintersection.
Your lines have tone of selfintersection , which is forbiden (because 
GEOS does topological computation)!


So now of to fixe this : use this function 
 
to transform your non-simple (multi)line into multiline where each 
line inside is simple.

You code becomes :

SELECT objectid, nom, code
, ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as 
offseted_linestring

FROM web.trs_itineraire , st_Dump(rc_MakeSimple(shape)) as dmp
WHERE code = '06-20B'

It execute successfully (now does it do what you expect, I don't know)
(tested on the data you shared, no translation, no snapping)
Cheers,
Rémi-C

 French version 

J'ai trouvé le problème je pense.
En fait les géométries ne sont pas simple au sens de PostGIS, c'est à 
dire "qui ne s'autointersecte pas".
Cela est interdit et cause les erreurs de GEOS (qui fait du calcul 
topologique).


Maintenant la solution pour régler simplement le problème :
utilisercette fonction 
 
pour passer de (multi)lignes avec des autointersections à des 
multilignes dont chaque lignes composante ne s'autointersecte pas.


Du coup,
votre code devient :
SELECT objectid, nom, code
, ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as 
offseted_linestring

FROM web.trs_itineraire , st_Dump(rc_MakeSimple(shape)) as dmp
WHERE code = '06-20B'

La requete s'execute sans erreurs (après le résultat ne sera pas 
nécessairement ce que vous attendez, mais c'est une autre histoire).
(testé sur les données que vous avez partagées, sans translation ni 
snapping).


Salutations,
Rémi-C

2015-02-03 9:12 GMT+01:00 Sandro Santilli >:


On Sun, Feb 01, 2015 at 08:46:16PM +0100, Rémi Cura wrote:

> We are coming closer to a GEOS or PostGIS bug.

Please use the bug tracker for these, thanks.

--strk;
___
postgis-users mailing list
postgis-users@lists.osgeo.org 
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users




___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users


--
Guillaume ARNAUD
Cellule SIGD
Direction de l'Informatique
Conseil Général de Tarn-et-Garonne


___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] English please (was: Get parallel some route.)

[Rémi Cura]

/*french version at the end*/
Ok I think I found the problem :
your geometry are not simple, that is in postgis langage, there is no
selfintersection.
Your lines have tone of selfintersection , which is forbiden (because GEOS
does topological computation)!

So now of to fixe this : use this function

to transform your non-simple (multi)line into multiline where each line
inside is simple.
You code becomes :

SELECT objectid, nom, code
, ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as
offseted_linestring
FROM web.trs_itineraire , st_Dump(rc_MakeSimple(shape)) as dmp
WHERE code = '06-20B'

It execute successfully (now does it do what you expect, I don't know)
(tested on the data you shared, no translation, no snapping)
Cheers,
Rémi-C

 French version 

J'ai trouvé le problème je pense.
En fait les géométries ne sont pas simple au sens de PostGIS, c'est à dire
"qui ne s'autointersecte pas".
Cela est interdit et cause les erreurs de GEOS (qui fait du calcul
topologique).

Maintenant la solution pour régler simplement le problème :
utiliser cette fonction

pour passer de (multi)lignes avec des autointersections à des multilignes
dont chaque lignes composante ne s'autointersecte pas.

Du coup,
votre code devient :
SELECT objectid, nom, code
, ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as
offseted_linestring
FROM web.trs_itineraire , st_Dump(rc_MakeSimple(shape)) as dmp
WHERE code = '06-20B'

La requete s'execute sans erreurs (après le résultat ne sera pas
nécessairement ce que vous attendez, mais c'est une autre histoire).
(testé sur les données que vous avez partagées, sans translation ni
snapping).

Salutations,
Rémi-C

2015-02-03 9:12 GMT+01:00 Sandro Santilli :

> On Sun, Feb 01, 2015 at 08:46:16PM +0100, Rémi Cura wrote:
>
> > We are coming closer to a GEOS or PostGIS bug.
>
> Please use the bug tracker for these, thanks.
>
> --strk;
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] English please (was: Get parallel some route.)

[Sandro Santilli]

On Sun, Feb 01, 2015 at 08:46:16PM +0100, Rémi Cura wrote:

> We are coming closer to a GEOS or PostGIS bug.

Please use the bug tracker for these, thanks.

--strk;
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] Convert from Lat/Long point to postGIS geometry

[KhunSanAung]

Hi Brent Wood,

Many thanks, it works.
UPDATE public.town SET geom = ST_SetSRID(ST_MakePoint(longitude, latitude),
4326);

I am using postGIS to store the data and using GeoServer for publishing the
data to maps.

I'm thinking to use the GeoExplorer (from OpenGeo Suite) for digitizing and
collecting the location information.
When using GeoExplorer, the geometry information is automatically stored to
the *geom* field of the table and the use have to fill all the attribute
again.

But I already have the full list in a postGIS table.
How can I make my application in such a way that user just need to select
from the list and digitizing the location only. No need to enter the
attribute again.

Many thanks for any  idea.

Best regards



On Tue, Feb 3, 2015 at 10:50 AM, Brent Wood  wrote:

> Hi.
>
> Try something like:
>
> update  set  = ST_SetSRID(ST_MakePoint(Longitude,
> Latitude),4326);
>
> Essentially create a point geometry from your numeric values, with the
> ST_MakePoint() function, the inform Postgis it is a standard lat/long CS
> (EPSG:4326 - which you should have specified when you created the column),
> & update the table with these values for each row. Make sure you use your
> table & column names
>
> What mapping/GIS program are you using?
>
> Cheers,
>
>   Brent Wood
>
>   --
>  *From:* KhunSanAung 
> *To:* postgis-users@lists.osgeo.org
> *Sent:* Tuesday, February 3, 2015 5:11 PM
> *Subject:* [postgis-users] Convert from Lat/Long point to postGIS geometry
>
> Hi All,
>
> I have one table (Town info) in postgres without Geometry field.
> I have Latitude and Longitude information for those points data separately
> (collecting & filling).
>
> I created the postGIS extension and add the Geometry field in the above
> postgres table.
> Now, I'd like to add the location information into the postGIS geometry
> field so that I can immediately view those points on the map.
>
> How can I convert the Latitude/Longitude value into postGIS geometry value?
>
> Thank you very much in advance.
>
> --
> Have a nice day!
> --
> *Mr. Khun San Aung*
> * *
>
> ___
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
>


-- 
Have a nice day!
--

*Mr. Khun San Aung*
* *
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users