Gregers Petersen | 2 Nov 2003 16:08
Picon

RPM Spec-file

Hello.

I am trying to build an "easy to maintain" system with PostGIS and
PostgreSQL. Therefore I am looking for a rpm-solution. We are currently
compiling from source, but it would be much easier for us to do the work
only once per version.

So does anyone have an idea of where I can find either up to date RPMs or a
spec file?

We are running Red Hat 7.3

--

-- 
Kindest regards

Gregers Petersen.
Mateusz Łoskot | 2 Nov 2003 22:21
Picon

WKB data in files

Hello,

I'm a new user of PostGIS and I'm very glad that there
is such a tool like PostGIS. Great tool !

Currently, I'm working on some application
based on OpenGIS geometry. I have to make some decisions
about the data format I will use in my application.
No, I'm using ESRI Shape file and such all geometries
from Shape to my geometry model (conformed to OpenGIS spec.).

ESRI Shape seems to not to fit as well as I'd wish in my solution.

So, I think that one of many possibilities is to use files in
Well-Known-Binary format. It sounds good, but I'm not sure
if specifications gives such a possibility.
As I know, WKB is defined in order to provide (quting OGC Spec.) :
"[...] a portable representation of Geometry value as a contiguous
stream of bytes. It permits Geometry values to be exchanged between
an ODBC client and an SQL database in binary form."

So, there is no word about using geometry encoded in WKB format
and store it in binary files.

The main question is: is it possible or recommended to store
Geometry in WKB format in binary files, similar as in ESRI Shape files ?

In my opinion, it should be, but it could be hard to implement it
because of some information omitted in WKB format i.e. header for file
with information about number of geometry objects, etc. (as in Shape).
(Continue reading)

Paul Ramsey | 2 Nov 2003 22:28
Favicon

Re: WKB data in files

I think you have hit the nail on the head. WKB is not really designed as 
  a file format, but as a transport format. Generally you would store 
shapes on disk as a GeometryCollection of some sort. But as with shape, 
you would need somewhere to store your attributes (an assocated file, 
hooray) and probably an index file to speed up access speed (another 
associated file, hooray).  And by then, you have reinvented the shape file.

Why is the shape file not suitable to you for on disk storage? There are 
numerous open source readers and writers in all sorts of languages. The 
shape file format is often abused, but the proliferation of standard 
read/write libraries has basically plastered over any lingering 
interoperability problems with the format.

Paul

Mateusz Łoskot wrote:

> In my opinion, it should be, but it could be hard to implement it
> because of some information omitted in WKB format i.e. header for file
> with information about number of geometry objects, etc. (as in Shape).
> If it is possible to use WKB in files, it could be useful to 
> create some WKB dumping tool. What do you think ?

--

-- 
       __
      /
      | Paul Ramsey
      | Refractions Research
      | Email: pramsey <at> refractions.net
      | Phone: (250) 885-0632
(Continue reading)

Mateusz Łoskot | 2 Nov 2003 22:49
Picon

Re: WKB data in files

On  02.11 2003 Paul Ramsey wrote:
> I think you have hit the nail on the head. WKB is not really designed as 
>  a file format, but as a transport format. Generally you would store 
> shapes on disk as a GeometryCollection of some sort. But as with shape, 
> you would need somewhere to store your attributes (an assocated file, 
> hooray) and probably an index file to speed up access speed (another 
> associated file, hooray).  And by then, you have reinvented the shape file.

In my simple solution, I'd like to use SQLite database to store
attributes and WKB files to store geometry. SQLite is considered
as analogy to dbf files in ESRI Shape.

> Why is the shape file not suitable to you for on disk storage? There are 
> numerous open source readers and writers in all sorts of languages. The 
> shape file format is often abused, but the proliferation of standard 
> read/write libraries has basically plastered over any lingering 
> interoperability problems with the format.

May be you are right. May be I misunderstand some points.
I think that Shape is not suitable to OpenGIS geometry model.
I'm not sure (I need time to have more experience),
if shapes types stored in Shapefile conform to the geometry model
defined by OpenGIS. Could you explain me that from your experience ?

I could store geometry directly in SQLite, but SQLite stores everything
as text, and encoding/decoding from text to binary could decrease
the performance. 
So, the main reasons I'm going to store WKB in files are:
- conformance with OpenGIS spec. / geometry model
- SQLite specifics
(Continue reading)

Andre Seifert | 3 Nov 2003 11:54
Picon

ERROR "LITTLE_ENDIAN" is undefined.

Hi folks, I need help.
During building PostGis by gmake the following message appears:

cc-1020 cc: ERROR File = postgis_debug.c, Line = 215
  The identifier "LITTLE_ENDIAN" is undefined.
                if (BYTE_ORDER == LITTLE_ENDIAN)
                    ^
IRIX 6.5 MIPS R12000
I have inserted the following line into postgis.h
#define BYTE_ORDER LITTLE_ENDIAN
But it was'nt the solution for my problem.
What must I do?
(After all, sorry for my lousy English.)

Mail scanned by virusscanner, Patternfile from 02 Nov 2003
Elstermann, Mike | 3 Nov 2003 15:25
Picon
Favicon

postgis/postgrsql/geos

hi,
i have a problem :-(
i'm working with suse 8.2 , postgresql 7.3.3, postgis 0.7.5 ... wonderful
:-)
now i want to use some spatial functions: intersects, ....
thats why i have installed GEOS (./configure, make, make install) ...
successfully :-)

but when I start a select with spatial function it doesn't works ???

for example: 
select disjoint(\'LINESTRING(0 0,0 0)\'::geometry, \'LINESTRING(0 0,0
1)\'::geometry );

Warning: pg_exec() query failed: ERROR: Function disjoint(geometry,
geometry) does not exist Unable to identify a function that satisfies the
given argument types You may need to add explicit typecasts 

where is the errors?

::: mfg. Mike Elstermann [mikeE.], Teamleiter GIS/RIS, e-Solutions
::: IT-Consult Halle GmbH, Bornknechtstraße 5, 06108 Halle (Saale)
::: Sitz: Große Nikolaistraße 8
::: Tel.: +49 345 221 4237, Fax: +49 345 221 4236, mobil: +49 160 71 545 02
::: mike.elstermann <at> itc-halle.de ::: http://www.itc-halle.de
::: GeoDaten Online? -> http://www.itcgis.de
Andre Seifert | 3 Nov 2003 16:20
Picon

Antw: ERROR "LITTLE_ENDIAN" is undefined.

The problem is solved by myself. I delved deeply and got the answer.
The most important change is made in postgis.h. The other changes are also needful to build by gmake. 

edit postgis.h:
  #include <sys/endian.h>

edit Makefile:
  subdir=../../postgis-0.7.5
  top_builddir = ../postgresql-7.3.4

edit loader/Makefile:
  subdir=../../postgis-0.7.5/loader
  top_builddir = ../../postgresql-7.3.4

>>> ASeifert <at> schwerin.de 03.11.2003  11.54 Uhr >>>
Hi folks, I need help.
During building PostGis by gmake the following message appears:

cc-1020 cc: ERROR File = postgis_debug.c, Line = 215
  The identifier "LITTLE_ENDIAN" is undefined.
                if (BYTE_ORDER == LITTLE_ENDIAN)
                    ^
IRIX 6.5 MIPS R12000
I have inserted the following line into postgis.h
#define BYTE_ORDER LITTLE_ENDIAN
But it was'nt the solution for my problem.
What must I do?
(After all, sorry for my lousy English.)

Mail scanned by virusscanner, Patternfile from 02 Nov 2003
(Continue reading)

Mark Cave-Ayland | 3 Nov 2003 16:33
Picon

RE: postgis/postgrsql/geos

Hi Mike,

As I understand it, installing GEOS only installs the library files
required to use the new geometry functions. To use the new functions in
postgresql, you will need to use the latest CVS version of PostGIS and
alter the makefile to ensure that it has been compiled with support for
the GEOS functions. Finally, you will have to re-run the postgis.sql
script into the database to allow postgresql to see the new function
definitions, so it may be a good idea to try this in a new database and
work from there.

Hope this helps,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
(Continue reading)

Menke, Kurt | 3 Nov 2003 19:03
Picon

ogr2ogr syntax???

Hi,
I am trying to implement ogr2ogr to convert a PostGIS view to a shapefile but cannot find any CLEAR examples of the syntax.  Especially for the arguments:

-dsco NAME=VALUE: Dataset creation option (format specific)
 -lco  NAME=VALUE: Layer creation option (format specific)

Does anyone have good examples of using this command especially specifying a PostgreSQL data source (view) and a path to an output shapefile?

Thanks

Kurt

~~~~~~~~~~~~~~~~~~~~~~~~~
Kurt A. Menke
GIS Analyst/Programmer

Mailing Address 
Earth Data Analysis Center
MSC01 1110
1 University of New Mexico
Albuquerque, New Mexico  87131-0001

Street Address
University of New Mexico
Bandelier West, Room 123
Albuquerque, NM 87131

Phone:  (505) 277-3622 (ext. 239)
FAX:  (505) 277-3614
email:  kmenke <at> edac.unm.edu

Frank Warmerdam | 3 Nov 2003 19:10
Picon
Favicon
Gravatar

Re: ogr2ogr syntax???

Menke, Kurt wrote:
> Hi,
> I am trying to implement ogr2ogr to convert a PostGIS view to a 
> shapefile but cannot find any CLEAR examples of the syntax.  Especially 
> for the arguments:
> 
> -dsco NAME=VALUE: Dataset creation option (format specific)
>  -lco  NAME=VALUE: Layer creation option (format specific)
> 
> Does anyone have good examples of using this command especially 
> specifying a PostgreSQL data source (view) and a path to an output 
> shapefile?

Kurt,

I just tested the following command to dump the poly table in the "test"
Postgres database to a shapefile called p2.shp and it worked fine.

   ogr2ogr p2.shp PG:dbname=test poly

The options available for the -dsco and -lco flags are driver specific.
In the case of the shapefile driver (as noted in the shapefile driver page
under supported formats) there is only one supported option, SHPT to set
the shapefile type.  By default I believe the shapefile type is determined
from the geometry type of the first feature written.  But if you wanted to
force the output to be a 3D polygon shapefile in the above case you might use:

   ogr2ogr p2.shp PG:dbname=test -lco SHPT=POLYGONZ poly

Some drivers, such as the PostGIS one itself, have a substantial list of
layer or even datasource creation options.

Best regards,

--

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

Gmane