[postgis-users] Coverages and PostGIS wiki page

[Bryce L Nordgren]

I just wrote a little deal which tries to tease out differences and 
similarities between raster/vector types using "coverage" concepts. I 
tried to be nontechnical. There's a pictorial "concept map" at the 
beginning too.

There's a temptation to gloss over the differences and just say "use 
raster as a column type the same way you'd use a geometry type". That 
won't work, as the differences are subtle but important. 

The crux of the article/tutorial/thingy is "what is the meaning of a table 
when it has these column types?" "what does a row represent?" etc.

Check it out and edit it to your heart's content.

http://trac.osgeo.org/postgis/wiki/UsersWikiCoveragesAndPostgis

Bryce___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Support for KNNGIST in PostGIS 2.0.0 Development Snapshot?

[Scholle]

Great... You may want to let me know so I can some extensive testing...


Paul Ramsey-4 wrote:
> 
> Not yet. Some time in the next 6-8 weeks.
> P.
> 
> On Thu, Jul 21, 2011 at 9:17 AM, Scholle  wrote:
>>
>> Hi,
>>
>> just asking whether support for KNNGIST has been added to current PostGIS
>> 2.0.0 Development Snapshot?
>>
>> Thanks, Scholle
>> --
>> View this message in context:
>> http://old.nabble.com/Support-for-KNNGIST-in-PostGIS-2.0.0-Development-Snapshot--tp32104130p32104130.html
>> Sent from the PostGIS - User mailing list archive at Nabble.com.
>>
>> ___
>> postgis-users mailing list
>> postgis-users@postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Support-for-KNNGIST-in-PostGIS-2.0.0-Development-Snapshot--tp32104130p32110371.html
Sent from the PostGIS - User mailing list archive at Nabble.com.

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] Raster image of Mexico City

[Roberto Andrade Fonseca]

Hi:

I'm looking for a raster image of Mexico Ciy (Federal District), but I
haven't find what I need.

The idea is tu put it on the background of some turistical points.

Where can I find it?

TIA.

-- 
Roberto Andrade Fonseca
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] raster outputs

[Pierre Racine]

> But how do I assign colors to each class, as in 0-20 = blue, 20-30 = purple, 
> etc?

Use ST_Reclass() to reclass your values to three R,G,B bands.

http://postgis.refractions.net/documentation/manual-svn/RT_ST_Reclass.html

Pierre


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] raster outputs

[Stephen Crawford]

But how do I assign colors to each class, as in 0-20 = blue, 20-30 = 
purple, etc?


Thanks,
Steve

On 7/21/2011 1:26 PM, Pierre Racine wrote:

I'm using postGIS raster to store daily weather data and it's working 
wonderfully
for the task at hand, which is to answer queries such as "get me the max temp
for the last 12 days at point X."  But next I would like to be able to output a
classified map of max temp (and other weather variables) as a PNG.  Could
someone point the way for me?

Once/if you have a raster representing your data you can use:

http://postgis.refractions.net/documentation/manual-svn/RT_ST_AsPNG.html
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


--
Stephen Crawford
Center for Environmental Informatics
The Pennsylvania State University
src...@psu.edu
814.865.9905


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Support for KNNGIST in PostGIS 2.0.0 Development Snapshot?

[Paul Ramsey]

Not yet. Some time in the next 6-8 weeks.
P.

On Thu, Jul 21, 2011 at 9:17 AM, Scholle  wrote:
>
> Hi,
>
> just asking whether support for KNNGIST has been added to current PostGIS
> 2.0.0 Development Snapshot?
>
> Thanks, Scholle
> --
> View this message in context: 
> http://old.nabble.com/Support-for-KNNGIST-in-PostGIS-2.0.0-Development-Snapshot--tp32104130p32104130.html
> Sent from the PostGIS - User mailing list archive at Nabble.com.
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] raster outputs

[Pierre Racine]

> I'm using postGIS raster to store daily weather data and it's working 
> wonderfully
> for the task at hand, which is to answer queries such as "get me the max temp
> for the last 12 days at point X."  But next I would like to be able to output 
> a
> classified map of max temp (and other weather variables) as a PNG.  Could
> someone point the way for me?

Once/if you have a raster representing your data you can use:

http://postgis.refractions.net/documentation/manual-svn/RT_ST_AsPNG.html
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] raster outputs

[Stephen Crawford]

I'm using postGIS raster to store daily weather data and it's working 
wonderfully for the task at hand, which is to answer queries such as 
"get me the max temp for the last 12 days at point X."  But next I would 
like to be able to output a classified map of max temp (and other 
weather variables) as a PNG.  Could someone point the way for me?


Thanks,
Steve

--
Stephen Crawford
Center for Environmental Informatics
The Pennsylvania State University
src...@psu.edu



___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] Support for KNNGIST in PostGIS 2.0.0 Development Snapshot?

[Scholle]

Hi, 

just asking whether support for KNNGIST has been added to current PostGIS
2.0.0 Development Snapshot? 

Thanks, Scholle 
-- 
View this message in context: 
http://old.nabble.com/Support-for-KNNGIST-in-PostGIS-2.0.0-Development-Snapshot--tp32104130p32104130.html
Sent from the PostGIS - User mailing list archive at Nabble.com.

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] How to get n largest (multi-)polygons contained in parent (multi-)polygon?

[Scholle]

Hi, 

having an arbitrary (multi-)polygon A of area a (ST_Area), I want to get the
n largest (B0...Bn) (multi-)polygons which are contained (ST_Contains) in A,
with ST_Area(B0) >= ST_Area(B1) >= ST_Area(B2),...

What I have got so far: 

CREATE OR REPLACE FUNCTION getplaceswithinplace(place_id int4, x int)
RETURNS SETOF places AS $$
DECLARE
cnt INT;
rr RECORD;
area float8;
parent RECORD;
BEGIN
  SELECT * INTO parent FROM places WHERE id = place_id;
  area := ST_Area(parent.geom_multi_polygon_xy_srid_4326);
  LOOP
SELECT COUNT(*) INTO cnt FROM places WHERE
ST_Area(geom_multi_polygon_xy_srid_4326) >= area &&
ST_Contains(parent.geom_multi_polygon_xy_srid_4326,
geom_multi_polygon_xy_srid_4326) LIMIT x;
IF FOUND AND cnt >= x THEN
  FOR rr IN (SELECT * FROM places WHERE
ST_Area(geom_multi_polygon_xy_srid_4326) >= area &&
ST_Contains(parent.geom_multi_polygon_xy_srid_4326,
geom_multi_polygon_xy_srid_4326) LIMIT x) LOOP
RETURN NEXT rr;
  END LOOP;
  RETURN;
ELSE
  area := area * 0.99;
END IF;
  END LOOP;
END;
$$ LANGUAGE plpgsql;

Just wondering how this piece of code might be improved...

Thanks for any feedback...


-- 
View this message in context: 
http://old.nabble.com/How-to-get-n-largest-%28multi-%29polygons-contained-in-parent-%28multi-%29polygon--tp32105569p32105569.html
Sent from the PostGIS - User mailing list archive at Nabble.com.

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[Richard White]

We run a production system that produces via OGR, amongst many other
vector formats, shapefiles for every version of ArcView and have never
had a problem with them being used by thousands of customers.

R.

-Original Message-
From: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: 21 July 2011 16:08
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Shapefiles exported from PostGIS and ESRI
ArcView 9 compatibility

There's no reason to think the Shape files produced by shp2pgsql won't
work in any and all versions of Arc.

P

On Thu, Jul 21, 2011 at 12:23 AM, Ben Madin
 wrote:
> G'dat all,
>
> We have a client (potential client) who wants some mapping done and
the maps returned in shapefile format. In the contract they insist on
specifying that the shapefiles are compatible with "ESRI's ArcView
version 9" (their words, not mine).
>
> I don't have "ESRI's ArcView version 9", and don't intend on spending
that sort of money (more than the contract is worth). However, I'm sure
that if what we send back doesn't open in "ESRI's ArcView version 9" it
will become our problem.
>
> Does anyone have any reason to suspect that a shapefile created using
valid OGC geometry in PostGIS and exported using pgsql2shp would not or
might not work on "ESRI's ArcView version 9"?
>
> Are there any issues that someone who is across platforms can help me
with?
>
> (I routinely use shapefiles created using valid OGC geometry in
PostGIS and exported using pgsql2shp in QGIS and MapServer and send them
to other people, so I have no reason to be concerned except that the
client insists on this line remaining the contract!)
>
> cheers
>
> Ben
>
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Infoterra Ltd. Is part of the Astrium GEO-Information Services Division and a 
wholly owned subsidiary of Astrium, Europe's leading space systems and services 
specialist.

Disclaimer. The information contained in this e-mail and its attachments are 
confidential and intended only for the use of the named addressee(s). If you 
are not the intended addressee, please do not read, copy, use or disclose this 
message or its attachments. If you have received this message in error, please 
notify the sender immediately and delete or destroy all copies of this message 
and attachments in all media. Any views or opinions expressed are solely those 
of the author and do not necessarily represent those of Infoterra Ltd and shall 
not form part of any binding agreement.

Infoterra Limited a company registered in England under number 2359955 and 
having its registered office at Atlas House, 41 Wembley Road, Leicester, LE3 
1UT. VAT number GB 476 0468 27. 

P Before printing, think about the environment 

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[Paul Ramsey]

There's no reason to think the Shape files produced by shp2pgsql won't
work in any and all versions of Arc.

P

On Thu, Jul 21, 2011 at 12:23 AM, Ben Madin
 wrote:
> G'dat all,
>
> We have a client (potential client) who wants some mapping done and the maps 
> returned in shapefile format. In the contract they insist on specifying that 
> the shapefiles are compatible with "ESRI's ArcView version 9" (their words, 
> not mine).
>
> I don't have "ESRI's ArcView version 9", and don't intend on spending that 
> sort of money (more than the contract is worth). However, I'm sure that if 
> what we send back doesn't open in "ESRI's ArcView version 9" it will become 
> our problem.
>
> Does anyone have any reason to suspect that a shapefile created using valid 
> OGC geometry in PostGIS and exported using pgsql2shp would not or might not 
> work on "ESRI's ArcView version 9"?
>
> Are there any issues that someone who is across platforms can help me with?
>
> (I routinely use shapefiles created using valid OGC geometry in PostGIS and 
> exported using pgsql2shp in QGIS and MapServer and send them to other people, 
> so I have no reason to be concerned except that the client insists on this 
> line remaining the contract!)
>
> cheers
>
> Ben
>
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[Ben Madin]

pvaldes

On 21/07/2011, at 10:41 PM, p valdes wrote:

> Thanks Ben, I'm trying to attack the problem with the geometry
> approach. I will add your correction just now

Not a correction, but your previous post didn't include the full list of points 
you were using to construct the polygon... so no one can test it to see if 
there is a problem. If you send the full list of points (or export the polygon 
so it can be imported) others can check to see where the problem might be.

cheers

Ben


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[p valdes]

Thanks Ben, I'm trying to attack the problem with the geometry
approach. I will add your correction just now

Its time for me to do some work, consult the manual and learn from my
mistakes. I will post the solution when I finished.
Thanks to all again

pvaldes
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[Nicolas Ribot]

> Hi Nicolas,
>
> I thought ST_Area should work with Geography types and return metres? Is this 
> not so?
>

Hmm you're right:
float ST_Area(geography g1);

I should RTFM more closely before replying :-o

Nicolas
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[Ben Madin]

p

Nicely documented example - but can you provide the full geography of the dam 
(that's Australian for pond!) maybe using st_astext() so other's can try on 
their local machines?

cheers

Ben


On 21/07/2011, at 8:42 PM, p valdes wrote:

> Hi,
> I'm trying to calculate the area of a polygon, with strange results...
> 
> First a description of the problem, the ugly details at the end of the post
> 
> I have measured the perimeter of a pond. An irregular
> polygon vaguely 'chop shaped' without holes or spikes
> and closed (beginning and ending in the same point).
> For simplification purposes let's suppose that I was
> expecting something like the left shape...
> well, I'm obtaining instead this:
> 
> expectedobtained
> ------
> |  |   |  |
> |  |   |  |
> |  |__|  |
> |  |   |  |
> ---|  |
>   |  |
>   |  |
>   |  |_
>   -
> 
> The right shape is "not right". The polygon is clearly
> stretched in the vertical North-South axis in the screen. The
> satellite google map support that the real shape of
> the pond is the first represented and I think the same...
> 
> Well I could live with this, but there's two more nasty consequences.
> 
> 1) If I take a point inside or related to the polygon
> in a separated map layer the point is drawn OUTSIDE
> and far away below the figure of the pond (note also that the
> pond is printed much more big than expect, because the relative distance
> between a and b is the same in both, and seems right). Graphically:
> 
> expected obtained
> 
> --*a   ---
> |  ||  |
> |  ||  |
> |  ||  |
> |  ||  |
> |  ||  |
> |  ||  |
> |  ||  |
> |  |_  |  |_
> -*b   --
> 
> 
> 
> 
> 
> 
>  *a
>  *b
> 
> Maybe a problem of the map viewer software, yes but the second
> question is more serious:
> 
> ST_distance calculates a distance between the "a" and "b" points of
> about 160 m for this rectangle. A max length of 160 m for this pond
> seems reasonable to me.
> 
> but ST_area calculates an area for this polygon of almost 7 ha!, for a
> polygon that could fit in a rectangle of about 160x50 m!.
> I'm obtaining a faked area about seven times BIGGER than real, uh-oh...
> 
> Its clear to me that I'm doing a very obvious and stupid mistake. I
> greatly appreciated if you could take a look at the problem or suggest
> any possible source of the error
> 
> Thanks in advance
> 
> pvaldes.
> 
> 
> 
> .
> Details
> ..
> 
> The points were registered with a garmin GPS as coordinates in degrees
> (ie: 43.254 N -4.839 W)
> 
> I'm using PostgreSQL 9.0.4
>  on i486-pc-linux-gnu, compiled by GCC gcc-4.6.real (Debian
> 4.6.0-6) 4.6.1 20110428 (prerelease), 32-bit
>  (obtained as Debian package from an official repository)
> 
> postgis-1.5.3
>  (downloaded and compiled from the tarfile at postgis.refractions.net)
> 
> This is the table
> 
> CREATE TABLE mytable(
> ref serial PRIMARY KEY,
> name varchar(80),
> perimeter geography(POLYGON,4326)
> );
> 
> The polygon with lat/lon coords was loaded with something like:
> 
> INSERT INTO mytable (perimeter, name)
> VALUES (
> ST_GeogFromText(
> 'POLYGON((
> -5.3850 43.230,
> -5.3858 43.231,
> -5.3859 43.245,
>   ...
> -5.3850 43.230
> ))', 4326),'myname');
> 
> And this is the very simple query returning strange results
> 
> SELECT st_area(mytable.perimeter)::double precision AS square_meters
> FROM mytable
> WHERE name = 'myname';
> 
> I use pgsql2shp for obtaining a shapefile that I'm loading with thuban
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[Ben Madin]

Hi Nicolas,

I thought ST_Area should work with Geography types and return metres? Is this 
not so?

cheers

Ben


On 21/07/2011, at 9:34 PM, Nicolas Ribot wrote:

> On 21 July 2011 14:42, p valdes  wrote:
>> Hi,
>> I'm trying to calculate the area of a polygon, with strange results...
>> 
>> First a description of the problem, the ugly details at the end of the post
>> 
>> I have measured the perimeter of a pond. An irregular
>> polygon vaguely 'chop shaped' without holes or spikes
>> and closed (beginning and ending in the same point).
>> For simplification purposes let's suppose that I was
>> expecting something like the left shape...
>> well, I'm obtaining instead this:
>> 
>> expectedobtained
>> ------
>> |  |   |  |
>> |  |   |  |
>> |  |__|  |
>> |  |   |  |
>> ---|  |
>>   |  |
>>   |  |
>>   |  |_
>>   -
>> 
>> The right shape is "not right". The polygon is clearly
>> stretched in the vertical North-South axis in the screen. The
>> satellite google map support that the real shape of
>> the pond is the first represented and I think the same...
>> 
>> Well I could live with this, but there's two more nasty consequences.
>> 
>> 1) If I take a point inside or related to the polygon
>> in a separated map layer the point is drawn OUTSIDE
>> and far away below the figure of the pond (note also that the
>> pond is printed much more big than expect, because the relative distance
>> between a and b is the same in both, and seems right). Graphically:
>> 
>> expected obtained
>> 
>> --*a   ---
>> |  ||  |
>> |  ||  |
>> |  ||  |
>> |  ||  |
>> |  ||  |
>> |  ||  |
>> |  ||  |
>> |  |_  |  |_
>> -*b   --
>> 
>> 
>> 
>> 
>> 
>> 
>>  *a
>>  *b
>> 
>> Maybe a problem of the map viewer software, yes but the second
>> question is more serious:
>> 
>> ST_distance calculates a distance between the "a" and "b" points of
>> about 160 m for this rectangle. A max length of 160 m for this pond
>> seems reasonable to me.
>> 
>> but ST_area calculates an area for this polygon of almost 7 ha!, for a
>> polygon that could fit in a rectangle of about 160x50 m!.
>>  I'm obtaining a faked area about seven times BIGGER than real, uh-oh...
>> 
>> Its clear to me that I'm doing a very obvious and stupid mistake. I
>> greatly appreciated if you could take a look at the problem or suggest
>> any possible source of the error
>> 
>> Thanks in advance
>> 
>> pvaldes.
>> 
>> 
>> 
>> .
>> Details
>> ..
>> 
>> The points were registered with a garmin GPS as coordinates in degrees
>> (ie: 43.254 N -4.839 W)
>> 
>> I'm using PostgreSQL 9.0.4
>>  on i486-pc-linux-gnu, compiled by GCC gcc-4.6.real (Debian
>> 4.6.0-6) 4.6.1 20110428 (prerelease), 32-bit
>>  (obtained as Debian package from an official repository)
>> 
>> postgis-1.5.3
>>  (downloaded and compiled from the tarfile at postgis.refractions.net)
>> 
>> This is the table
>> 
>> CREATE TABLE mytable(
>> ref serial PRIMARY KEY,
>> name varchar(80),
>> perimeter geography(POLYGON,4326)
>> );
>> 
>> The polygon with lat/lon coords was loaded with something like:
>> 
>> INSERT INTO mytable (perimeter, name)
>> VALUES (
>> ST_GeogFromText(
>> 'POLYGON((
>> -5.3850 43.230,
>> -5.3858 43.231,
>> -5.3859 43.245,
>>   ...
>> -5.3850 43.230
>> ))', 4326),'myname');
>> 
>> And this is the very simple query returning strange results
>> 
>> SELECT st_area(mytable.perimeter)::double precision AS square_meters
>> FROM mytable
>> WHERE name = 'myname';
>> 
>> I use pgsql2shp for obtaining a shapefile that I'm loading with thuban
> 
> 
> Hi,
> st_area works with data units, degrees in your case.
> So you are computing square degrees, which has no geographic meaning.
> You should project your data to a metric system and then perform area
> computation on the projected data.
> North of Spain corresponds to UTM 30N (SRID 32630).
> 
> Nicolas
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[David Fawcett]

As George points out, there is a published spec.

I build shapefiles using tools based on OGR (and pgsql2shp) often and
they work fine with ArcGIS products.

On thing to note.  The spatial and attribute index file specifications
are not public.  So, the client may want to build these index files
once they receive the data.  Without them, you have a complete and
fully functioning shapefile, but people will often want to add these
indexes to increase performance.

David.

On Thu, Jul 21, 2011 at 6:53 AM, George Rodrigues da Cunha Silva
 wrote:
> Em quinta-feira, 21 de julho de 2011 08:15:43, MarkW escreveu:
>>
>> Do the shptree and related shapefile utilities that come with the osgeo
>> installs apply here? I've only used them in association with MapServer, so I
>> don't know if shptree's indexes are usable by ESRI software.
>>
>> Mark
>>
>> On Thu, Jul 21, 2011 at 3:23 AM, Ben Madin > > wrote:
>>
>>    G'dat all,
>>
>>    We have a client (potential client) who wants some mapping done and
>>    the maps returned in shapefile format. In the contract they insist
>>    on specifying that the shapefiles are compatible with "ESRI's
>>    ArcView version 9" (their words, not mine).
>>
>>    I don't have "ESRI's ArcView version 9", and don't intend on
>>    spending that sort of money (more than the contract is worth).
>>    However, I'm sure that if what we send back doesn't open in "ESRI's
>>    ArcView version 9" it will become our problem.
>>
>>    Do
>
> es anyone have any reason to suspect that a shapefile created
>>
>>    using valid OGC geometry in PostGIS and exported using pgsql2shp
>>    would not or might not work on "ESRI's ArcView version 9"?
>>
>>    Are there any issues that someone who is across platforms can help
>>    me with?
>>
>>    (I routinely use shapefiles created using valid OGC geometry in
>>    PostGIS and exported using pgsql2shp in QGIS and MapServer and send
>>    them to other people, so I have no reason to be concerned except
>>    that the client insists on this line remaining the contract!)
>>
>>    cheers
>>
>>    Ben
>>
>>
>>    ___
>>    postgis-users mailing list
>>    postgis-users@postgis.refractions.net
>>    
>>    http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>>
>>
>> ___
>> postgis-users mailing list
>> postgis-users@postgis.refractions.n
>
> et
>>
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> There is an open specification of the shapefile format
>
> http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
>
> Shape is still the 'de facto' format for exchanging GIS data. I can't think
> of anything else right now.
>
> Regarding compatibility, they are compatible AFAIK. Never had an issue.
>
> George
>
> --
> 
> George Rodrigues da Cunha Silva
> Desenvolvedor GIS
> http://geoprocessamento.net
> http://blog.geoprocessamento.net
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[p valdes]

Thanks also James.  Well, in fact the idea was to avoid geometry. I
was using geometry fields in the past but the new geography type
sounds so seductive... :-)

Well at least until I improve my postgis skills, you're right, I
should return to mess with geometry types by now.

pvaldes

2011/7/21 James David Smith :
> Dear pvaldes,

> Have you tried to do this with type 'geometry' instead of 'geography' ?

> James
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[Nicolas Ribot]

On 21 July 2011 15:44, p valdes  wrote:
> mmmh... I see
>
> Thanks a lot for your advice Nicolas, I will follow your clue and
> investigate about how to do this
>

Something like:

SELECT st_area(st_transform(mytable.perimeter, 32630)) AS square_meters
FROM mytable
WHERE name = 'myname';

Should give you areas in square meters.

Nicolas
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[p valdes]

mmmh... I see

Thanks a lot for your advice Nicolas, I will follow your clue and
investigate about how to do this

pvaldes


> st_area works with data units, degrees in your case.
> So you are computing square degrees, which has no geographic meaning.
> You should project your data to a metric system and then perform area
> computation on the projected data.
> North of Spain corresponds to UTM 30N (SRID 32630).
>
> Nicolas
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[James David Smith]

Dear pvaldes,

Have you tried to do this with type 'geometry' instead of 'geography' ?

James



On 21 July 2011 13:42, p valdes  wrote:
> Hi,
> I'm trying to calculate the area of a polygon, with strange results...
>
> First a description of the problem, the ugly details at the end of the post
>
> I have measured the perimeter of a pond. An irregular
> polygon vaguely 'chop shaped' without holes or spikes
> and closed (beginning and ending in the same point).
> For simplification purposes let's suppose that I was
> expecting something like the left shape...
> well, I'm obtaining instead this:
>
> expected    obtained
> ---            ---
> |      |           |  |
> |      |           |  |
> |      |__        |  |
> |          |       |  |
> ---        |  |
>                   |  |
>                   |  |
>                   |  |_
>                   -
>
> The right shape is "not right". The polygon is clearly
> stretched in the vertical North-South axis in the screen. The
> satellite google map support that the real shape of
> the pond is the first represented and I think the same...
>
> Well I could live with this, but there's two more nasty consequences.
>
> 1) If I take a point inside or related to the polygon
> in a separated map layer the point is drawn OUTSIDE
> and far away below the figure of the pond (note also that the
> pond is printed much more big than expect, because the relative distance
> between a and b is the same in both, and seems right). Graphically:
>
> expected     obtained
>
> --*a               ---
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |_              |  |_
> -*b           --
>
>
>
>
>
>
>                      *a
>                      *b
>
> Maybe a problem of the map viewer software, yes but the second
> question is more serious:
>
> ST_distance calculates a distance between the "a" and "b" points of
> about 160 m for this rectangle. A max length of 160 m for this pond
> seems reasonable to me.
>
> but ST_area calculates an area for this polygon of almost 7 ha!, for a
> polygon that could fit in a rectangle of about 160x50 m!.
>  I'm obtaining a faked area about seven times BIGGER than real, uh-oh...
>
> Its clear to me that I'm doing a very obvious and stupid mistake. I
> greatly appreciated if you could take a look at the problem or suggest
> any possible source of the error
>
> Thanks in advance
>
> pvaldes.
>
>
>
> .
> Details
> ..
>
> The points were registered with a garmin GPS as coordinates in degrees
> (ie: 43.254 N -4.839 W)
>
> I'm using PostgreSQL 9.0.4
>          on i486-pc-linux-gnu, compiled by GCC gcc-4.6.real (Debian
> 4.6.0-6) 4.6.1 20110428 (prerelease), 32-bit
>          (obtained as Debian package from an official repository)
>
> postgis-1.5.3
>      (downloaded and compiled from the tarfile at postgis.refractions.net)
>
> This is the table
>
> CREATE TABLE mytable(
> ref serial PRIMARY KEY,
> name varchar(80),
> perimeter geography(POLYGON,4326)
> );
>
> The polygon with lat/lon coords was loaded with something like:
>
> INSERT INTO mytable (perimeter, name)
> VALUES (
> ST_GeogFromText(
> 'POLYGON((
> -5.3850 43.230,
> -5.3858 43.231,
> -5.3859 43.245,
>   ...
> -5.3850 43.230
> ))', 4326),'myname');
>
> And this is the very simple query returning strange results
>
> SELECT st_area(mytable.perimeter)::double precision AS square_meters
> FROM mytable
> WHERE name = 'myname';
>
> I use pgsql2shp for obtaining a shapefile that I'm loading with thuban
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[Nicolas Ribot]

On 21 July 2011 14:42, p valdes  wrote:
> Hi,
> I'm trying to calculate the area of a polygon, with strange results...
>
> First a description of the problem, the ugly details at the end of the post
>
> I have measured the perimeter of a pond. An irregular
> polygon vaguely 'chop shaped' without holes or spikes
> and closed (beginning and ending in the same point).
> For simplification purposes let's suppose that I was
> expecting something like the left shape...
> well, I'm obtaining instead this:
>
> expected    obtained
> ---            ---
> |      |           |  |
> |      |           |  |
> |      |__        |  |
> |          |       |  |
> ---        |  |
>                   |  |
>                   |  |
>                   |  |_
>                   -
>
> The right shape is "not right". The polygon is clearly
> stretched in the vertical North-South axis in the screen. The
> satellite google map support that the real shape of
> the pond is the first represented and I think the same...
>
> Well I could live with this, but there's two more nasty consequences.
>
> 1) If I take a point inside or related to the polygon
> in a separated map layer the point is drawn OUTSIDE
> and far away below the figure of the pond (note also that the
> pond is printed much more big than expect, because the relative distance
> between a and b is the same in both, and seems right). Graphically:
>
> expected     obtained
>
> --*a               ---
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |_              |  |_
> -*b           --
>
>
>
>
>
>
>                      *a
>                      *b
>
> Maybe a problem of the map viewer software, yes but the second
> question is more serious:
>
> ST_distance calculates a distance between the "a" and "b" points of
> about 160 m for this rectangle. A max length of 160 m for this pond
> seems reasonable to me.
>
> but ST_area calculates an area for this polygon of almost 7 ha!, for a
> polygon that could fit in a rectangle of about 160x50 m!.
>  I'm obtaining a faked area about seven times BIGGER than real, uh-oh...
>
> Its clear to me that I'm doing a very obvious and stupid mistake. I
> greatly appreciated if you could take a look at the problem or suggest
> any possible source of the error
>
> Thanks in advance
>
> pvaldes.
>
>
>
> .
> Details
> ..
>
> The points were registered with a garmin GPS as coordinates in degrees
> (ie: 43.254 N -4.839 W)
>
> I'm using PostgreSQL 9.0.4
>          on i486-pc-linux-gnu, compiled by GCC gcc-4.6.real (Debian
> 4.6.0-6) 4.6.1 20110428 (prerelease), 32-bit
>          (obtained as Debian package from an official repository)
>
> postgis-1.5.3
>      (downloaded and compiled from the tarfile at postgis.refractions.net)
>
> This is the table
>
> CREATE TABLE mytable(
> ref serial PRIMARY KEY,
> name varchar(80),
> perimeter geography(POLYGON,4326)
> );
>
> The polygon with lat/lon coords was loaded with something like:
>
> INSERT INTO mytable (perimeter, name)
> VALUES (
> ST_GeogFromText(
> 'POLYGON((
> -5.3850 43.230,
> -5.3858 43.231,
> -5.3859 43.245,
>   ...
> -5.3850 43.230
> ))', 4326),'myname');
>
> And this is the very simple query returning strange results
>
> SELECT st_area(mytable.perimeter)::double precision AS square_meters
> FROM mytable
> WHERE name = 'myname';
>
> I use pgsql2shp for obtaining a shapefile that I'm loading with thuban


Hi,
st_area works with data units, degrees in your case.
So you are computing square degrees, which has no geographic meaning.
You should project your data to a metric system and then perform area
computation on the projected data.
North of Spain corresponds to UTM 30N (SRID 32630).

Nicolas
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

[p valdes]

Hi,
I'm trying to calculate the area of a polygon, with strange results...

First a description of the problem, the ugly details at the end of the post

I have measured the perimeter of a pond. An irregular
polygon vaguely 'chop shaped' without holes or spikes
and closed (beginning and ending in the same point).
For simplification purposes let's suppose that I was
expecting something like the left shape...
well, I'm obtaining instead this:

expectedobtained
------
|  |   |  |
|  |   |  |
|  |__|  |
|  |   |  |
---|  |
   |  |
   |  |
   |  |_
   -

The right shape is "not right". The polygon is clearly
stretched in the vertical North-South axis in the screen. The
satellite google map support that the real shape of
the pond is the first represented and I think the same...

Well I could live with this, but there's two more nasty consequences.

1) If I take a point inside or related to the polygon
in a separated map layer the point is drawn OUTSIDE
and far away below the figure of the pond (note also that the
pond is printed much more big than expect, because the relative distance
between a and b is the same in both, and seems right). Graphically:

expected obtained

--*a   ---
|  ||  |
|  ||  |
|  ||  |
|  ||  |
|  ||  |
|  ||  |
|  ||  |
|  |_  |  |_
-*b   --






  *a
  *b

Maybe a problem of the map viewer software, yes but the second
question is more serious:

ST_distance calculates a distance between the "a" and "b" points of
about 160 m for this rectangle. A max length of 160 m for this pond
seems reasonable to me.

but ST_area calculates an area for this polygon of almost 7 ha!, for a
polygon that could fit in a rectangle of about 160x50 m!.
 I'm obtaining a faked area about seven times BIGGER than real, uh-oh...

Its clear to me that I'm doing a very obvious and stupid mistake. I
greatly appreciated if you could take a look at the problem or suggest
any possible source of the error

Thanks in advance

pvaldes.



.
Details
..

The points were registered with a garmin GPS as coordinates in degrees
(ie: 43.254 N -4.839 W)

I'm using PostgreSQL 9.0.4
  on i486-pc-linux-gnu, compiled by GCC gcc-4.6.real (Debian
4.6.0-6) 4.6.1 20110428 (prerelease), 32-bit
  (obtained as Debian package from an official repository)

postgis-1.5.3
  (downloaded and compiled from the tarfile at postgis.refractions.net)

This is the table

CREATE TABLE mytable(
ref serial PRIMARY KEY,
name varchar(80),
perimeter geography(POLYGON,4326)
);

The polygon with lat/lon coords was loaded with something like:

INSERT INTO mytable (perimeter, name)
VALUES (
ST_GeogFromText(
'POLYGON((
-5.3850 43.230,
-5.3858 43.231,
-5.3859 43.245,
   ...
-5.3850 43.230
))', 4326),'myname');

And this is the very simple query returning strange results

SELECT st_area(mytable.perimeter)::double precision AS square_meters
FROM mytable
WHERE name = 'myname';

I use pgsql2shp for obtaining a shapefile that I'm loading with thuban
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Accumulated segment length of a linestring

[Ralf Suhr]

Hello Stefan,


Am Donnerstag 21 Juli 2011, 13:47:46 schrieb Stephan Holl:
> Hello Ralf,
> 
> "Ralf Suhr" , [20110721 - 13:43:59]
> 
> > Hello Stefan,
> > 
> > use a trigger on table romy_2010 for fast calculating. You need only
> > to add the new segment length to the last summary length.
> 
> the table is a point-table, but maybe I do not get your point.

Yes, the point-table can have a new column "segment_length" wich will be 
filled by a trigger. The trigger need to know the length from the last segment 
and the distance between the last and the new point. The sum will be stored in 
the new column.

> 
> > And you can't use st_makeline() on a point table without ordering the
> > points.
> 
> I do not want. They are ordered by gid (which is a serial though, see
> below).

indeed st_makeline() is order by gid.

> 
> Best
>   Stephan
> 
> > Am Donnerstag 21 Juli 2011, 11:47:53 schrieb Stephan Holl:
> > > Dear PostGIS-users,
> > > 
> > > I would like to calculate the accumulated lengths of each
> > > linestring-segments into a new column, so that every segment holds
> > > the real length from the beginning of the linestring. The last
> > > segment of the linestring shows the overall length of the
> > > linestring then.
> > > 
> > > My data (GPS POINT-data):
> > > CREATE TABLE romy_2010 (
> > > 
> > > gid integer NOT NULL,
> > > id double precision,
> > > tag_zeit date,
> > > the_geom public.geometry,
> > > veroeffentlicht smallint DEFAULT 0,
> > > bild text,
> > > link text,
> > > beschreibung text,
> > > CONSTRAINT enforce_dims_the_geom CHECK ((public.ndims(the_geom)
> > > 
> > > = 2)), CONSTRAINT enforce_geotype_the_geom CHECK
> > > (((public.geometrytype(the_geom) = 'POINT'::text) OR (the_geom IS
> > > NULL))), CONSTRAINT enforce_srid_the_geom CHECK
> > > ((public.srid(the_geom) = 4326)) );
> > > 
> > > My current linestring representing the vertexes and additional
> > > information:
> > > CREATE OR REPLACE VIEW v_romy_2010_foo AS
> > > SELECT
> > > 
> > > 'Romy'::text as storkname,
> > > n AS gid,
> > > n AS id,
> > > to_char(s.tag_zeit::timestamp, 'DD.MM.') AS zeit,
> > > s.beschreibung,
> > > s.bild,
> > > s.link,
> > > -- segments
> > > st_makeline(st_PointN(m.the_geom,n), st_PointN(m.the_geom,
> > > 
> > > n+1)) AS the_geom,
> > > 
> > > round(st_length_spheroid(st_makeline(st_PointN(m.the_geom,n),
> > > 
> > >   st_PointN(m.the_geom, n+1)), 'SPHEROID["WGS
> > > 
> > > 84",6378137,298.257223563]')/1000) AS length_sphero_inKM
> > > 
> > >  FROM
> > >  
> > >   (SELECT
> > >   
> > > st_makeline(the_geom) AS the_geom
> > >
> > >FROM
> > >
> > > (SELECT
> > > 
> > > gid,
> > > beschreibung,
> > > the_geom
> > >  
> > >  FROM romy_2010 WHERE gid >= 1 AND veroeffentlicht = 1 ORDER
> > > 
> > > BY gid ) AS t
> > > 
> > >   ) AS m
> > >  
> > >  CROSS JOIN generate_series(1,1000) AS n
> > >  LEFT JOIN romy_2010 s ON s.id = n
> > >  WHERE n < st_npoints(m.the_geom);
> > > 
> > > I appreciate any pointers how to solve this.
> > > 
> > > TIA
> > > 
> > > Best regards
> > > 
> > >   Stephan

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[George Rodrigues da Cunha Silva]

Em quinta-feira, 21 de julho de 2011 08:15:43, MarkW escreveu:
Do the shptree and related shapefile utilities that come with the osgeo 
installs apply here? I've only used them in association with MapServer, 
so I don't know if shptree's indexes are usable by ESRI software.


Mark

On Thu, Jul 21, 2011 at 3:23 AM, Ben Madin 
mailto:li...@remoteinformation.com.au>> 
wrote:


G'dat all,

We have a client (potential client) who wants some mapping done and
the maps returned in shapefile format. In the contract they insist
on specifying that the shapefiles are compatible with "ESRI's
ArcView version 9" (their words, not mine).

I don't have "ESRI's ArcView version 9", and don't intend on
spending that sort of money (more than the contract is worth).
However, I'm sure that if what we send back doesn't open in "ESRI's
ArcView version 9" it will become our problem.

Do

es anyone have any reason to suspect that a shapefile created

using valid OGC geometry in PostGIS and exported using pgsql2shp
would not or might not work on "ESRI's ArcView version 9"?

Are there any issues that someone who is across platforms can help
me with?

(I routinely use shapefiles created using valid OGC geometry in
PostGIS and exported using pgsql2shp in QGIS and MapServer and send
them to other people, so I have no reason to be concerned except
that the client insists on this line remaining the contract!)

cheers

Ben


___
postgis-users mailing list
postgis-users@postgis.refractions.net

http://postgis.refractions.net/mailman/listinfo/postgis-users




___
postgis-users mailing list
postgis-users@postgis.refractions.n

et

http://postgis.refractions.net/mailman/listinfo/postgis-users


There is an open specification of the shapefile format

http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf

Shape is still the 'de facto' format for exchanging GIS data. I can't 
think of anything else right now.


Regarding compatibility, they are compatible AFAIK. Never had an issue.

George

--

George Rodrigues da Cunha Silva
Desenvolvedor GIS
http://geoprocessamento.net
http://blog.geoprocessamento.net
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Accumulated segment length of a linestring

[Stephan Holl]

Hello Ralf,

"Ralf Suhr" , [20110721 - 13:43:59]

> Hello Stefan,
> 
> use a trigger on table romy_2010 for fast calculating. You need only
> to add the new segment length to the last summary length.

the table is a point-table, but maybe I do not get your point.
 
> And you can't use st_makeline() on a point table without ordering the
> points.

I do not want. They are ordered by gid (which is a serial though, see
below).

Best
Stephan

> Am Donnerstag 21 Juli 2011, 11:47:53 schrieb Stephan Holl:
> > Dear PostGIS-users,
> > 
> > I would like to calculate the accumulated lengths of each
> > linestring-segments into a new column, so that every segment holds
> > the real length from the beginning of the linestring. The last
> > segment of the linestring shows the overall length of the
> > linestring then.
> > 
> > My data (GPS POINT-data):
> > CREATE TABLE romy_2010 (
> > gid integer NOT NULL,
> > id double precision,
> > tag_zeit date,
> > the_geom public.geometry,
> > veroeffentlicht smallint DEFAULT 0,
> > bild text,
> > link text,
> > beschreibung text,
> > CONSTRAINT enforce_dims_the_geom CHECK ((public.ndims(the_geom)
> > = 2)), CONSTRAINT enforce_geotype_the_geom CHECK
> > (((public.geometrytype(the_geom) = 'POINT'::text) OR (the_geom IS
> > NULL))), CONSTRAINT enforce_srid_the_geom CHECK
> > ((public.srid(the_geom) = 4326)) );
> > 
> > My current linestring representing the vertexes and additional
> > information:
> > CREATE OR REPLACE VIEW v_romy_2010_foo AS
> > SELECT
> > 'Romy'::text as storkname,
> > n AS gid,
> > n AS id,
> > to_char(s.tag_zeit::timestamp, 'DD.MM.') AS zeit,
> > s.beschreibung,
> > s.bild,
> > s.link,
> > -- segments
> > st_makeline(st_PointN(m.the_geom,n), st_PointN(m.the_geom,
> > n+1)) AS the_geom,
> > round(st_length_spheroid(st_makeline(st_PointN(m.the_geom,n),
> >   st_PointN(m.the_geom, n+1)), 'SPHEROID["WGS
> > 84",6378137,298.257223563]')/1000) AS length_sphero_inKM
> >  FROM
> >   (SELECT
> > st_makeline(the_geom) AS the_geom
> >FROM
> > (SELECT
> > gid,
> > beschreibung,
> > the_geom
> >  FROM romy_2010 WHERE gid >= 1 AND veroeffentlicht = 1 ORDER
> > BY gid ) AS t
> >   ) AS m
> >  CROSS JOIN generate_series(1,1000) AS n
> >  LEFT JOIN romy_2010 s ON s.id = n
> >  WHERE n < st_npoints(m.the_geom);
> > 
> > 
> > I appreciate any pointers how to solve this.
> > 
> > TIA
> > 
> > Best regards
> > 
> > Stephan
> 



-- 
Stephan Holl  | Tel.: +49 (0)541-33 508 3663
Intevation GmbH, Neuer Graben 17, 49074 OS  |  AG Osnabrück - HR B 18998
Geschäftsführer:  Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: PGP signature
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Accumulated segment length of a linestring

[Ralf Suhr]

Hello Stefan,

use a trigger on table romy_2010 for fast calculating. You need only to add 
the new segment length to the last summary length.

And you can't use st_makeline() on a point table without ordering the points.

Gr
Ralf

Am Donnerstag 21 Juli 2011, 11:47:53 schrieb Stephan Holl:
> Dear PostGIS-users,
> 
> I would like to calculate the accumulated lengths of each
> linestring-segments into a new column, so that every segment holds the
> real length from the beginning of the linestring. The last segment of
> the linestring shows the overall length of the linestring then.
> 
> My data (GPS POINT-data):
> CREATE TABLE romy_2010 (
> gid integer NOT NULL,
> id double precision,
> tag_zeit date,
> the_geom public.geometry,
> veroeffentlicht smallint DEFAULT 0,
> bild text,
> link text,
> beschreibung text,
> CONSTRAINT enforce_dims_the_geom CHECK ((public.ndims(the_geom) =
> 2)), CONSTRAINT enforce_geotype_the_geom CHECK
> (((public.geometrytype(the_geom) = 'POINT'::text) OR (the_geom IS
> NULL))), CONSTRAINT enforce_srid_the_geom CHECK ((public.srid(the_geom)
> = 4326)) );
> 
> My current linestring representing the vertexes and additional
> information:
> CREATE OR REPLACE VIEW v_romy_2010_foo AS
> SELECT
> 'Romy'::text as storkname,
> n AS gid,
> n AS id,
> to_char(s.tag_zeit::timestamp, 'DD.MM.') AS zeit,
> s.beschreibung,
> s.bild,
> s.link,
> -- segments
> st_makeline(st_PointN(m.the_geom,n), st_PointN(m.the_geom, n+1)) AS
> the_geom,
> round(st_length_spheroid(st_makeline(st_PointN(m.the_geom,n),
>   st_PointN(m.the_geom, n+1)), 'SPHEROID["WGS
> 84",6378137,298.257223563]')/1000) AS length_sphero_inKM
>  FROM
>   (SELECT
> st_makeline(the_geom) AS the_geom
>FROM
> (SELECT
> gid,
> beschreibung,
> the_geom
>  FROM romy_2010 WHERE gid >= 1 AND veroeffentlicht = 1 ORDER
> BY gid ) AS t
>   ) AS m
>  CROSS JOIN generate_series(1,1000) AS n
>  LEFT JOIN romy_2010 s ON s.id = n
>  WHERE n < st_npoints(m.the_geom);
> 
> 
> I appreciate any pointers how to solve this.
> 
> TIA
> 
> Best regards
> 
>   Stephan

___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[MarkW]

Do the shptree and related shapefile utilities that come with the osgeo
installs apply here? I've only used them in association with MapServer, so I
don't know if shptree's indexes are usable by ESRI software.

Mark

On Thu, Jul 21, 2011 at 3:23 AM, Ben Madin
wrote:

> G'dat all,
>
> We have a client (potential client) who wants some mapping done and the
> maps returned in shapefile format. In the contract they insist on specifying
> that the shapefiles are compatible with "ESRI's ArcView version 9" (their
> words, not mine).
>
> I don't have "ESRI's ArcView version 9", and don't intend on spending that
> sort of money (more than the contract is worth). However, I'm sure that if
> what we send back doesn't open in "ESRI's ArcView version 9" it will become
> our problem.
>
> Does anyone have any reason to suspect that a shapefile created using valid
> OGC geometry in PostGIS and exported using pgsql2shp would not or might not
> work on "ESRI's ArcView version 9"?
>
> Are there any issues that someone who is across platforms can help me with?
>
> (I routinely use shapefiles created using valid OGC geometry in PostGIS and
> exported using pgsql2shp in QGIS and MapServer and send them to other
> people, so I have no reason to be concerned except that the client insists
> on this line remaining the contract!)
>
> cheers
>
> Ben
>
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] Accumulated segment length of a linestring

[Stephan Holl]

Dear PostGIS-users,

I would like to calculate the accumulated lengths of each
linestring-segments into a new column, so that every segment holds the
real length from the beginning of the linestring. The last segment of
the linestring shows the overall length of the linestring then.

My data (GPS POINT-data):
CREATE TABLE romy_2010 (
gid integer NOT NULL,
id double precision,
tag_zeit date,
the_geom public.geometry,
veroeffentlicht smallint DEFAULT 0,
bild text,
link text,
beschreibung text,
CONSTRAINT enforce_dims_the_geom CHECK ((public.ndims(the_geom) =
2)), CONSTRAINT enforce_geotype_the_geom CHECK
(((public.geometrytype(the_geom) = 'POINT'::text) OR (the_geom IS
NULL))), CONSTRAINT enforce_srid_the_geom CHECK ((public.srid(the_geom)
= 4326)) );

My current linestring representing the vertexes and additional
information:
CREATE OR REPLACE VIEW v_romy_2010_foo AS 
SELECT
'Romy'::text as storkname, 
n AS gid, 
n AS id,  
to_char(s.tag_zeit::timestamp, 'DD.MM.') AS zeit, 
s.beschreibung, 
s.bild, 
s.link,
-- segments
st_makeline(st_PointN(m.the_geom,n), st_PointN(m.the_geom, n+1)) AS
the_geom,
round(st_length_spheroid(st_makeline(st_PointN(m.the_geom,n),
  st_PointN(m.the_geom, n+1)), 'SPHEROID["WGS
84",6378137,298.257223563]')/1000) AS length_sphero_inKM 
 FROM 
  (SELECT 
st_makeline(the_geom) AS the_geom 
   FROM
(SELECT 
gid, 
beschreibung, 
the_geom
 FROM romy_2010 WHERE gid >= 1 AND veroeffentlicht = 1 ORDER
BY gid ) AS t
  ) AS m 
 CROSS JOIN generate_series(1,1000) AS n
 LEFT JOIN romy_2010 s ON s.id = n  
 WHERE n < st_npoints(m.the_geom);


I appreciate any pointers how to solve this.

TIA

Best regards

Stephan

-- 
Stephan Holl  | Tel.: +49 (0)541-33 508 3663
Intevation GmbH, Neuer Graben 17, 49074 OS  |  AG Osnabrück - HR B 18998
Geschäftsführer:  Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: PGP signature
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[Phil Bartie]

Maybe download the free ESRI arc explorer to test it out
http://www.esri.com/software/arcgis/explorer/index.html
On Jul 21, 2011 3:23 PM, "Ben Madin"  wrote:
> G'dat all,
>
> We have a client (potential client) who wants some mapping done and the
maps returned in shapefile format. In the contract they insist on specifying
that the shapefiles are compatible with "ESRI's ArcView version 9" (their
words, not mine).
>
> I don't have "ESRI's ArcView version 9", and don't intend on spending that
sort of money (more than the contract is worth). However, I'm sure that if
what we send back doesn't open in "ESRI's ArcView version 9" it will become
our problem.
>
> Does anyone have any reason to suspect that a shapefile created using
valid OGC geometry in PostGIS and exported using pgsql2shp would not or
might not work on "ESRI's ArcView version 9"?
>
> Are there any issues that someone who is across platforms can help me
with?
>
> (I routinely use shapefiles created using valid OGC geometry in PostGIS
and exported using pgsql2shp in QGIS and MapServer and send them to other
people, so I have no reason to be concerned except that the client insists
on this line remaining the contract!)
>
> cheers
>
> Ben
>
>
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[Andreas Forø Tollefsen]

I am unsure about the details, but can only talk for myself. I have exported
a lot of PostGIS data to shapefiles without ever having a problem.
Both geometry and attribute table seem to be working without a hitch.

Andreas

2011/7/21 Maria Arias de Reyna 

> El Jueves 21 Julio 2011, Ben Madin escribió:
> > We have a client (potential client) who wants some mapping done and the
> > maps returned in shapefile format. In the contract they insist on
> > specifying that the shapefiles are compatible with "ESRI's ArcView
> version
> > 9" (their words, not mine).
>
> If ArcView has no public specification of their Shapefiles, you can always
> tell
> your potential client all the problems derivated from using a privative and
> dark format. In fact, you *should* at least mention it.
>
> It will save you a lot of troubles in the future. If you explain it right,
> clients usually understand it and _sometimes_ they agree to move to open
> formats.
>
>
> Anyway, you should ask your client for a couple of examples of their
> shapefiles
> and compare them with yours. Maybe the difference is small and you can
> post-
> process your generated shapefiles to adjust them.
>
> --
> María Arias de Reyna Domínguez
> Área de Operaciones
>
> Emergya Consultoría
> Tfno: +34 954 51 75 77 / +34 607 43 74 27
> Fax: +34 954 51 64 73
> www.emergya.es
> ___
> postgis-users mailing list
> postgis-users@postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[Maria Arias de Reyna]

El Jueves 21 Julio 2011, Ben Madin escribió:
> We have a client (potential client) who wants some mapping done and the
> maps returned in shapefile format. In the contract they insist on
> specifying that the shapefiles are compatible with "ESRI's ArcView version
> 9" (their words, not mine). 

If ArcView has no public specification of their Shapefiles, you can always tell 
your potential client all the problems derivated from using a privative and 
dark format. In fact, you *should* at least mention it.

It will save you a lot of troubles in the future. If you explain it right, 
clients usually understand it and _sometimes_ they agree to move to open 
formats.


Anyway, you should ask your client for a couple of examples of their shapefiles 
and compare them with yours. Maybe the difference is small and you can post-
process your generated shapefiles to adjust them.

-- 
María Arias de Reyna Domínguez
Área de Operaciones

Emergya Consultoría 
Tfno: +34 954 51 75 77 / +34 607 43 74 27
Fax: +34 954 51 64 73 
www.emergya.es 
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

Re: [postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[Peter Hopfgartner]

Since there is no official spec for "shapefiles", there are some 
differences between the different shapefiles producers and consumers.
Shapefiles produced with current PostGIS 1.5.3 should be reasonable 
ready for ArcView. We, and even more some of our customers, open PostGIS 
produced Shapefiles with ESRI product regularly.


Peter

On 07/21/2011 09:23 AM, Ben Madin wrote:

G'dat all,

We have a client (potential client) who wants some mapping done and the maps returned in 
shapefile format. In the contract they insist on specifying that the shapefiles are 
compatible with "ESRI's ArcView version 9" (their words, not mine).

I don't have "ESRI's ArcView version 9", and don't intend on spending that sort of money 
(more than the contract is worth). However, I'm sure that if what we send back doesn't open in 
"ESRI's ArcView version 9" it will become our problem.

Does anyone have any reason to suspect that a shapefile created using valid OGC geometry 
in PostGIS and exported using pgsql2shp would not or might not work on "ESRI's 
ArcView version 9"?

Are there any issues that someone who is across platforms can help me with?

(I routinely use shapefiles created using valid OGC geometry in PostGIS and 
exported using pgsql2shp in QGIS and MapServer and send them to other people, 
so I have no reason to be concerned except that the client insists on this line 
remaining the contract!)

cheers

Ben


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users

[postgis-users] Shapefiles exported from PostGIS and ESRI ArcView 9 compatibility

[Ben Madin]

G'dat all,

We have a client (potential client) who wants some mapping done and the maps 
returned in shapefile format. In the contract they insist on specifying that 
the shapefiles are compatible with "ESRI's ArcView version 9" (their words, not 
mine). 

I don't have "ESRI's ArcView version 9", and don't intend on spending that sort 
of money (more than the contract is worth). However, I'm sure that if what we 
send back doesn't open in "ESRI's ArcView version 9" it will become our 
problem. 

Does anyone have any reason to suspect that a shapefile created using valid OGC 
geometry in PostGIS and exported using pgsql2shp would not or might not work on 
"ESRI's ArcView version 9"?

Are there any issues that someone who is across platforms can help me with?

(I routinely use shapefiles created using valid OGC geometry in PostGIS and 
exported using pgsql2shp in QGIS and MapServer and send them to other people, 
so I have no reason to be concerned except that the client insists on this line 
remaining the contract!)

cheers

Ben


___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users