Re: [postgis-users] Topology: cannot delete slivers (or gaps)

[Rémi Cura]

Note you could have directly exported into postgis topology, which is slow
but very convenient (stil faster than postgis topology conversion).
I'm not a grass user,
from what I understood you have to use the "-l" switch in the command "
*v.out.postgis*"

Glad it helped =)
Cheers,
Rémi-C

2014-11-10 13:56 GMT+01:00 Humberto Cereser Ibanez <
humbe...@pastoraldacrianca.org.br>:

> I was with the same problem, getting gaps in some adjacent polygons
> while trying to simplify polygons with Postgis.
> Thank Guillaume / Rémi / Sandro by the contributions.
> Illuminated by this thread, I created a script in which I avoided gaps
> from the bad polygons. Really the most appropriate tool, GRASS, became
> this work easier.
>
> On Fri, 2014-11-07 at 13:14 -0800, Guillaume Drolet wrote:
> > I finally finished cleaning my topology, using a mix of SQL commands,
> > functions, and also using Sandro's QGIS topology editor plugin.
> >
> > In parallel, I also tried going the GRASS route, importing my original
> > shapefile in GRASS and applying the cleaning function (v.clean ...) as
> > suggested by Remi. I injected the result into PostGIS and created a
> > topology. Most of the 23 slivers were there in the topology so one of two
> > things: 1) GRASS didn't fix them (maybe I didn't choose an appropriate
> > tolerance) or 2) they were created by PostGIS when building the topology.
> Simplifying polygons with QGIS and GRASS
>Note: SRID = 4326
> 1) Open shapefile in QGIS
> 2) Create New Mapset
> Import Extent from opened Shapefile
> 3) Check the smaller area of the polygons involved
> select ST_Area (geo_polygon) from table order by
> ST_Area(geo_polygon);
> Smaller area = 0.005471
> 4) Import shapefile into GRASS
> v.in.ogr dsn = /home/humberto/shapefiles/pr/41MUE250GC_SIR.shp
> output = prGrass snap = 0.0001 min_area = 0.004 -o
> Settings of parameters: Snapping threshold for boundaries = 0.0001
> and Minimum size of area to be imported (squere units) = 0.004
> Note: The 0.004 value was chosen to allow importing of the smaller
> area = 0.005 and all areas greater than it, avoiding any small ring that
> would be arising from this importing.
> 5) Simplify the Shapefile polygon imported
> v.generalize input=prGrass@elimSlivers type=area layer=1 -c
> type=boundary method=douglas threshold=0.001 look_ahead=7 reduction=50
> slide=0.5 angle_thresh=3 degree_thresh=0 closeness_thresh=0
> betweeness_thresh=0 alpha=1.0 beta=1.0 iterations=1
> output=prGrassGeneralized
> Settings of parameters: threshold = 0.001
> Note: the threshold value 0.001 was chosen by trial
> 6) Export the simplified polygon to Postgis
>v.out.ogr.pg.py input=prGrassGeneralized@elimSlivers type=area
> layer=1 olayer=prgeneralized database=simp22 host=127.0.0.1 port=5432
> user=name password=nonono
>
> >
> > Anyway, I got what I finally got what I need, thanks a lot to all of you
> who
> > helped me.
> >
> > I'm gonna ask you one last thing if I may: I want to replace the original
> > geom column (i.e. that used to build the topogeom) with a topologically
> > correct one, and keep all the associated ecological attributes. Is this
> the
> > right way to do it:
> >
> > UPDATE syshiera.de_20k SET geom = topogeom::geometry; ?
> >
> > Thanks.
> >
> >
> >
> > --
> > View this message in context:
> http://postgis.17.x6.nabble.com/Topology-cannot-delete-slivers-or-gaps-tp5007250p5007286.html
> > Sent from the PostGIS - User mailing list archive at Nabble.com.
> > ___
> > postgis-users mailing list
> > postgis-users@lists.osgeo.org
> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
> Thanks,
>
> Humberto
>
> ___
> 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] FileGDB curves

[Rémi Cura]

Hey,
first qgis can't deal with curve (i think),
so your data may be curved in your postgis but the visualisation would be
incorrect
 so if you are going to see some curve in qgis, you have to convert the
curve to approximate theim using http://postgis.net/docs/ST_CurveToLine.html
,
then display the geom
(you can do this in a view if you don't want to duplicate data)

Now if you are really really sure that data in postgis is bad (use
ST_AsTExt(geom) for example to see if anything look like curve)
Either you approximate your curve with multiline and convert it back to
curve with postgis
(http://postgis.net/docs/ST_LineToCurve.html)

Or you have to go the long way and pass the curves as attributes, and
reconstruct it afterward.
This seems like a very bad idea.

I'm afraid curve support is very very limited in all gis tools.

Cheers,
Rémi-C

2014-11-12 0:00 GMT+01:00 Andy Colson :

> Hi All,
>
> Not sure where the best place to ask this, so I'll start here.
>
> I have a FileGDB that contains some curved lines, I import it into PostGIS
> and they come out as chopped off Multiline.
>
> Here are some screen shots to help explain:
>
> Here is arc viewing the .gdb:
> http://testmaps.camavision.com/arc.png
>
> Here is qgis viewing PostGIS:
> http://testmaps.camavision.com/qgis.png
>
>
> I tried to get arcCatalog to export to shapefile, but something went bad
> and I cannot even look at the .shp files.
>
> Any hints how I can get the curve back?
>
> Thanks for your time,
>
> -Andy
> ___
> 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] FileGDB curves

[Andy Colson]

Mapserver displays it the same way:

http://testmaps.camavision.com/map/washingtonmn?pin=16.028.21.11.0039

The data looks like:

gis=# select st_AsText(the_geom) from streets where gid = 11517;
-[ RECORD 1 
]--
st_astext | MULTILINESTRING((-10344354.4038468 
5608573.22422463,-10344363.9860388 5608565.68874797,-10344398.9885982 
5608528.81799097,-10344438.5518419 5608468.68094317,-10344404.2129173 
5608265.5414558,-10344355.0291817 5608227.92219317,-10344239.0250123 
5608196.3261761,-10344230.7760714 5608197.59004929,-10344187.3835781 
5608212.14184435))




So I'm assuming that its a convert problem, not a display problem.

I'm not sure how to use ST_LineToCurve.  This is a road layer and 
everything is a MULTILINESTRING, I can't tell the straight from the 
curves.  Can I?


Thanks,

-Andy



On 11/12/2014 3:58 AM, Rémi Cura wrote:

Hey,
first qgis can't deal with curve (i think),
so your data may be curved in your postgis but the visualisation would
be incorrect
  so if you are going to see some curve in qgis, you have to convert the
curve to approximate theim using
http://postgis.net/docs/ST_CurveToLine.html,
then display the geom
(you can do this in a view if you don't want to duplicate data)

Now if you are really really sure that data in postgis is bad (use
ST_AsTExt(geom) for example to see if anything look like curve)
Either you approximate your curve with multiline and convert it back to
curve with postgis
(http://postgis.net/docs/ST_LineToCurve.html)

Or you have to go the long way and pass the curves as attributes, and
reconstruct it afterward.
This seems like a very bad idea.

I'm afraid curve support is very very limited in all gis tools.

Cheers,
Rémi-C

2014-11-12 0:00 GMT+01:00 Andy Colson mailto:a...@squeakycode.net>>:

Hi All,

Not sure where the best place to ask this, so I'll start here.

I have a FileGDB that contains some curved lines, I import it into
PostGIS and they come out as chopped off Multiline.

Here are some screen shots to help explain:

Here is arc viewing the .gdb:
http://testmaps.camavision.__com/arc.png


Here is qgis viewing PostGIS:
http://testmaps.camavision.__com/qgis.png



I tried to get arcCatalog to export to shapefile, but something went
bad and I cannot even look at the .shp files.

Any hints how I can get the curve back?

Thanks for your time,

-Andy


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

Re: [postgis-users] FileGDB curves

[Rémi Cura]

Good, you narrowed the error.

The function would do it for you,
it would convert the curved parts into curves and the straight part into
segment,
forming a curved polygon, which is a set of curve and segments.

But I'm affraid your line must appoximate the curves to have a result.
Your 2 first screen shots indicate that the curve information is simply
gone.

You can manually approximate curves into line in arcgis before export,
or maybe OGR driver for arcgis support curves
(http://www.gdal.org/drv_filegdb.html)

Cheers,
Rémi-C



2014-11-12 15:56 GMT+01:00 Andy Colson :

> Mapserver displays it the same way:
>
> http://testmaps.camavision.com/map/washingtonmn?pin=16.028.21.11.0039
>
> The data looks like:
>
> gis=# select st_AsText(the_geom) from streets where gid = 11517;
> -[ RECORD 1 ]---
> 
> 
> 
> 
> ---
> st_astext | MULTILINESTRING((-10344354.4038468 
> 5608573.22422463,-10344363.9860388
> 5608565.68874797,-10344398.9885982 5608528.81799097,-10344438.5518419
> 5608468.68094317,-10344404.2129173 5608265.5414558,-10344355.0291817
> 5608227.92219317,-10344239.0250123 5608196.3261761,-10344230.7760714
> 5608197.59004929,-10344187.3835781 5608212.14184435))
>
>
>
> So I'm assuming that its a convert problem, not a display problem.
>
> I'm not sure how to use ST_LineToCurve.  This is a road layer and
> everything is a MULTILINESTRING, I can't tell the straight from the
> curves.  Can I?
>
> Thanks,
>
> -Andy
>
>
>
> On 11/12/2014 3:58 AM, Rémi Cura wrote:
>
>> Hey,
>> first qgis can't deal with curve (i think),
>> so your data may be curved in your postgis but the visualisation would
>> be incorrect
>>   so if you are going to see some curve in qgis, you have to convert the
>> curve to approximate theim using
>> http://postgis.net/docs/ST_CurveToLine.html,
>> then display the geom
>> (you can do this in a view if you don't want to duplicate data)
>>
>> Now if you are really really sure that data in postgis is bad (use
>> ST_AsTExt(geom) for example to see if anything look like curve)
>> Either you approximate your curve with multiline and convert it back to
>> curve with postgis
>> (http://postgis.net/docs/ST_LineToCurve.html)
>>
>> Or you have to go the long way and pass the curves as attributes, and
>> reconstruct it afterward.
>> This seems like a very bad idea.
>>
>> I'm afraid curve support is very very limited in all gis tools.
>>
>> Cheers,
>> Rémi-C
>>
>> 2014-11-12 0:00 GMT+01:00 Andy Colson > >:
>>
>> Hi All,
>>
>> Not sure where the best place to ask this, so I'll start here.
>>
>> I have a FileGDB that contains some curved lines, I import it into
>> PostGIS and they come out as chopped off Multiline.
>>
>> Here are some screen shots to help explain:
>>
>> Here is arc viewing the .gdb:
>> http://testmaps.camavision.__com/arc.png
>> 
>>
>> Here is qgis viewing PostGIS:
>> http://testmaps.camavision.__com/qgis.png
>> 
>>
>>
>> I tried to get arcCatalog to export to shapefile, but something went
>> bad and I cannot even look at the .shp files.
>>
>> Any hints how I can get the curve back?
>>
>> Thanks for your time,
>>
>> -Andy
>>
>
> ___
> 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] FileGDB curves

[Andy Colson]

Yeah, I think the info is gone, because ST_LineToCurve looks the same. 
As a test I changed my map file from:


DATA 'the_geom FROM washingtonmn.streets using unique gid using srid=3857'

TO:

DATA 'the_geom FROM (select gid, fullstreet, st_LineToCurve(the_geom) as 
the_geom from washingtonmn.streets) as subq using unique gid using 
srid=3857'


And it displays the same either way.

I am using FileGDB:

ogrinfo -so WCWebDataCC.gdb/
INFO: Open of `WCWebDataCC.gdb/'
  using driver `FileGDB' successful.


The command I'm using is:

ogr2ogr -f PostgreSQL
  -lco FID=gid
  -lco SPATIAL_INDEX=OFF
  -lco GEOMETRY_NAME=the_geom
  -lco SCHEMA=washingtonmn
  -lco PRECISION=NO
  -lco DIM=2
  -t_srs EPSG:3857
  -nlt MULTILINESTRING
  'PG:dbname=gis'
  WCWebDataCC.gdb

Is the "-nlt MULTILINESTRING" doing bad things?  Its in there because 
some times I get layers marked as LINESTRING that dont convert so I just 
up them to MULTILINESTRING to get it to go.


Thanks again,

-Andy

On 11/12/2014 9:03 AM, Rémi Cura wrote:


Good, you narrowed the error.

The function would do it for you,
it would convert the curved parts into curves and the straight part into
segment,
forming a curved polygon, which is a set of curve and segments.

But I'm affraid your line must appoximate the curves to have a result.
Your 2 first screen shots indicate that the curve information is simply
gone.

You can manually approximate curves into line in arcgis before export,
or maybe OGR driver for arcgis support curves
(http://www.gdal.org/drv_filegdb.html)

Cheers,
Rémi-C



2014-11-12 15:56 GMT+01:00 Andy Colson mailto:a...@squeakycode.net>>:

Mapserver displays it the same way:

http://testmaps.camavision.__com/map/washingtonmn?pin=16.__028.21.11.0039


The data looks like:

gis=# select st_AsText(the_geom) from streets where gid = 11517;
-[ RECORD 1

]-__--__--__--__--__--__--__--__--__--__--__-
st_astext | MULTILINESTRING((-10344354.__4038468
5608573.22422463,-10344363.__9860388
5608565.68874797,-10344398.__9885982
5608528.81799097,-10344438.__5518419
5608468.68094317,-10344404.__2129173
5608265.5414558,-10344355.__0291817
5608227.92219317,-10344239.__0250123
5608196.3261761,-10344230.__7760714
5608197.59004929,-10344187.__3835781 5608212.14184435))



So I'm assuming that its a convert problem, not a display problem.

I'm not sure how to use ST_LineToCurve.  This is a road layer and
everything is a MULTILINESTRING, I can't tell the straight from the
curves.  Can I?

Thanks,

-Andy



On 11/12/2014 3:58 AM, Rémi Cura wrote:

Hey,
first qgis can't deal with curve (i think),
so your data may be curved in your postgis but the visualisation
would
be incorrect
   so if you are going to see some curve in qgis, you have to
convert the
curve to approximate theim using
http://postgis.net/docs/ST___CurveToLine.html
,
then display the geom
(you can do this in a view if you don't want to duplicate data)

Now if you are really really sure that data in postgis is bad (use
ST_AsTExt(geom) for example to see if anything look like curve)
Either you approximate your curve with multiline and convert it
back to
curve with postgis
(http://postgis.net/docs/ST___LineToCurve.html
)

Or you have to go the long way and pass the curves as
attributes, and
reconstruct it afterward.
This seems like a very bad idea.

I'm afraid curve support is very very limited in all gis tools.

Cheers,
Rémi-C

2014-11-12 0:00 GMT+01:00 Andy Colson mailto:a...@squeakycode.net>
>>__:

 Hi All,

 Not sure where the best place to ask this, so I'll start here.

 I have a FileGDB that contains some curved lines, I import
it into
 PostGIS and they come out as chopped off Multiline.

 Here are some screen shots to help explain:

 Here is arc viewing the .gdb:
http://testmaps.camavision.com/arc.png
 >

 Here is qgis viewing PostGIS:
http://testmaps.camavision.com/qgis.png
 

Re: [postgis-users] FileGDB curves

[Andy Colson]

Shoot.  I changed the command to:

ogr2ogr
  -f PostgreSQL
  -t_srs EPSG:3857
  'PG:dbname=gis'
  WCWebDataCC.gdb
  -lco FID=gid
  -lco SPATIAL_INDEX=OFF
  -lco GEOMETRY_NAME=the_geom
  -lco SCHEMA=washingtonmn
  -lco PRECISION=NO
  streets


(removing the -nlt) and I still get a MULTILINESTRING, and it still 
looks the same.


The ogr2ogr is part of a perl script, and the first command I posted was 
my guess at what it generated, which was a little off.  The command 
above is correct.


I'm not sure what else to try.

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

Re: [postgis-users] FileGDB curves

[Bborie Park]

If I remember correctly, curve geometries are not currently supported in
GDAL/OGR. There is a GDAL RFC making the rounds for adding curve support...

http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries

-bborie

On Wed, Nov 12, 2014 at 7:44 AM, Andy Colson  wrote:

> Shoot.  I changed the command to:
>
> ogr2ogr
>   -f PostgreSQL
>   -t_srs EPSG:3857
>   'PG:dbname=gis'
>   WCWebDataCC.gdb
>   -lco FID=gid
>   -lco SPATIAL_INDEX=OFF
>   -lco GEOMETRY_NAME=the_geom
>   -lco SCHEMA=washingtonmn
>   -lco PRECISION=NO
>   streets
>
>
> (removing the -nlt) and I still get a MULTILINESTRING, and it still looks
> the same.
>
> The ogr2ogr is part of a perl script, and the first command I posted was
> my guess at what it generated, which was a little off.  The command above
> is correct.
>
> I'm not sure what else to try.
>
>
> -Andy
> ___
> 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] FileGDB curves

[Paul Ramsey]

Correct, the curves were likely ruined on the way through GDAL. In
some ways, fortunate they ever got through at all.

On Wed, Nov 12, 2014 at 7:48 AM, Bborie Park  wrote:
> If I remember correctly, curve geometries are not currently supported in
> GDAL/OGR. There is a GDAL RFC making the rounds for adding curve support...
>
> http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries
>
> -bborie
>
> On Wed, Nov 12, 2014 at 7:44 AM, Andy Colson  wrote:
>>
>> Shoot.  I changed the command to:
>>
>> ogr2ogr
>>   -f PostgreSQL
>>   -t_srs EPSG:3857
>>   'PG:dbname=gis'
>>   WCWebDataCC.gdb
>>   -lco FID=gid
>>   -lco SPATIAL_INDEX=OFF
>>   -lco GEOMETRY_NAME=the_geom
>>   -lco SCHEMA=washingtonmn
>>   -lco PRECISION=NO
>>   streets
>>
>>
>> (removing the -nlt) and I still get a MULTILINESTRING, and it still looks
>> the same.
>>
>> The ogr2ogr is part of a perl script, and the first command I posted was
>> my guess at what it generated, which was a little off.  The command above is
>> correct.
>>
>> I'm not sure what else to try.
>>
>>
>> -Andy
>> ___
>> 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
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

Re: [postgis-users] FileGDB curves

[Rémi Cura]

So it seems you are stuck with approximating curve with line inside FileGDB
before using ogr.

I guess you can do so using arcgis, but I never used it.

Cheers,
Rémi-C

2014-11-12 17:09 GMT+01:00 Paul Ramsey :

> Correct, the curves were likely ruined on the way through GDAL. In
> some ways, fortunate they ever got through at all.
>
> On Wed, Nov 12, 2014 at 7:48 AM, Bborie Park  wrote:
> > If I remember correctly, curve geometries are not currently supported in
> > GDAL/OGR. There is a GDAL RFC making the rounds for adding curve
> support...
> >
> > http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries
> >
> > -bborie
> >
> > On Wed, Nov 12, 2014 at 7:44 AM, Andy Colson 
> wrote:
> >>
> >> Shoot.  I changed the command to:
> >>
> >> ogr2ogr
> >>   -f PostgreSQL
> >>   -t_srs EPSG:3857
> >>   'PG:dbname=gis'
> >>   WCWebDataCC.gdb
> >>   -lco FID=gid
> >>   -lco SPATIAL_INDEX=OFF
> >>   -lco GEOMETRY_NAME=the_geom
> >>   -lco SCHEMA=washingtonmn
> >>   -lco PRECISION=NO
> >>   streets
> >>
> >>
> >> (removing the -nlt) and I still get a MULTILINESTRING, and it still
> looks
> >> the same.
> >>
> >> The ogr2ogr is part of a perl script, and the first command I posted was
> >> my guess at what it generated, which was a little off.  The command
> above is
> >> correct.
> >>
> >> I'm not sure what else to try.
> >>
> >>
> >> -Andy
> >> ___
> >> 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
> ___
> 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] FileGDB curves

[Andy Colson]

I only use arc to convert stuff, otherwise I avoid it.  I don't even 
know how to edit with it.


This is only one curve, there are probably lots and lots in the layer.

Guess I'll try gdb -> shapefile again.  Have had some luck with that in 
the past.


Thanks all,

-Andy

On 11/12/2014 10:15 AM, Rémi Cura wrote:

So it seems you are stuck with approximating curve with line inside
FileGDB before using ogr.

I guess you can do so using arcgis, but I never used it.

Cheers,
Rémi-C

2014-11-12 17:09 GMT+01:00 Paul Ramsey mailto:pram...@cleverelephant.ca>>:

Correct, the curves were likely ruined on the way through GDAL. In
some ways, fortunate they ever got through at all.

On Wed, Nov 12, 2014 at 7:48 AM, Bborie Park mailto:dustym...@gmail.com>> wrote:
 > If I remember correctly, curve geometries are not currently
supported in
 > GDAL/OGR. There is a GDAL RFC making the rounds for adding curve
support...
 >
 > http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries
 >
 > -bborie
 >
 > On Wed, Nov 12, 2014 at 7:44 AM, Andy Colson
mailto:a...@squeakycode.net>> wrote:
 >>
 >> Shoot.  I changed the command to:
 >>
 >> ogr2ogr
 >>   -f PostgreSQL
 >>   -t_srs EPSG:3857
 >>   'PG:dbname=gis'
 >>   WCWebDataCC.gdb
 >>   -lco FID=gid
 >>   -lco SPATIAL_INDEX=OFF
 >>   -lco GEOMETRY_NAME=the_geom
 >>   -lco SCHEMA=washingtonmn
 >>   -lco PRECISION=NO
 >>   streets
 >>
 >>
 >> (removing the -nlt) and I still get a MULTILINESTRING, and it
still looks
 >> the same.
 >>
 >> The ogr2ogr is part of a perl script, and the first command I
posted was
 >> my guess at what it generated, which was a little off.  The
command above is
 >> correct.
 >>
 >> I'm not sure what else to try.
 >>
 >>
 >> -Andy
 >> ___
 >> 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
___
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



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

[postgis-users] no .bat in windows zip installers

[Rémi Cura]

Hey everybody.
The 2 bat files
makepostgisdb_using_extensions.bat
and
makepostgisdb.bat

seems to have vanished from the zip release file for version newer than
2.1.1 (postgis-bundle-pg93x64-2.1.1)

I'm I missing something?
thanks,
cheers,
Rémi-C
___
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

[postgis-users] Geographic Type Documentation Correction

[Andy Anderson]

Hi, I just noticed that on this page:

http://postgis.net/docs/using_postgis_dbmanagement.html#PostGIS_Geography

there are a number of references to “sphere” when they should instead say 
“spheroid”, and to “great circle arc” when they should instead say “geodesic”.

This is clear from the subsequent discussion, in particular in the FAQ section:

http://postgis.net/docs/using_postgis_dbmanagement.html#idp32988960

where it says


4.2.3.1.


Do you calculate on the sphere or the spheroid?



By default, all distance and area calculations are done on the spheroid. You 
should find that the results of calculations in local areas match up will with 
local planar results in good local projections. Over larger areas, the 
spheroidal calculations will be more accurate than any calculation done on a 
projected plane.

All the geography functions have the option of using a sphere calculation, by 
setting a final boolean parameter to 'FALSE'. This will somewhat speed up 
calculations, particularly for cases where the geometries are very simple.


So in

4.2. PostGIS Geography Type

the corrected documentation would change:

The basis for the PostGIS geographic type is a sphere. The shortest path 
between two points on the sphere is a great circle arc. That means that 
calculations on geographies (areas, distances, lengths, intersections, etc) 
must be calculated on the sphere, using more complicated mathematics. For more 
accurate measurements, the calculations must take the actual spheroidal shape 
of the world into account, and the mathematics becomes very complicated indeed.

to:

The basis for the PostGIS geographic type is a spheroid, a “squashed” sphere 
whose polar diameter is smaller than its equatorial diameter. The shortest path 
between two points on the sphere is a great circle arc, and on a spheroid it’s 
a similar arc called a geodesic. That means that calculations on geographies 
(areas, distances, lengths, intersections, etc) will provide more accurate 
measurements, but the calculations must take the actual spheroidal shape of the 
world into account, and the mathematics becomes very complicated indeed.

and in

4.2.3.3. What is the longest arc you can process?

the corrected documentation would change:

We use great circle arcs as the "interpolation line" between two points. That 
means any two points are actually joined up two ways, depending on which 
direction you travel along the great circle. All our code assumes that the 
points are joined by the *shorter* of the two paths along the great circle. As 
a consequence, shapes that have arcs of more than 180 degrees will not be 
correctly modelled.

to:

We use geodesics as the "interpolation line" between two points (these are 
great circle arcs on spheres). That means any two points are actually joined up 
two ways, depending on which direction you travel between them. All our code 
assumes that the points are joined by the *shorter* of the two paths. As a 
consequence, shapes that have arcs of more than 180 degrees will not be 
correctly modeled.

Cheers,

— Andy

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

Re: [postgis-users] FileGDB curves [SOLVED]

[Andy Colson]

On 11/12/2014 10:20 AM, Andy Colson wrote:


Guess I'll try gdb -> shapefile again.  Have had some luck with that in
the past.



If I use ArcCatalog to convert GDB to Shapefile, then the shapefile 
displays nicely in QGis, but its in some weird projection that ogr2ogr 
cant seem to reproject correctly.  It runs but then PostGIS has lots of 
nans instead of numbers.


So I tried to use ArcCatalogs to re-project into EPSG:3857, and then use 
ogr2ogr to import into PostGIS.  Then I get this error:


ogr2ogr -f PostgreSQL -lco FID=gid -lco SPATIAL_INDEX=OFF -lco 
GEOMETRY_NAME=the_geom -lco SCHEMA=washingtonmn -lco PRECISION=NO -lco 
DIM=2 -t_srs EPSG:3857 -nlt MULTILINESTRING 'PG:dbname=gis' 
DimensionLeader.shp


ERROR 6: No translation for Mercator_Auxiliary_Sphere to PROJ.4 format 
is known.

Failed to create coordinate transformation between the
following coordinate systems.  This may be because they
are not transformable, or because projection services
(PROJ.4 DLL/.so) could not be loaded.
Source:
PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",
GEOGCS["GCS_WGS_1984",
DATUM["WGS_1984",
SPHEROID["WGS_84",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Mercator_Auxiliary_Sphere"],
PARAMETER["False_Easting",0.0],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",0.0],
PARAMETER["Standard_Parallel_1",0.0],
PARAMETER["Auxiliary_Sphere_Type",0.0],
UNIT["Meter",1.0]]
Target:
PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH],
EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext 
+no_defs"],

AUTHORITY["EPSG","3857"]]
ERROR 1: Terminating translation prematurely after failed
translation of layer DimensionLeader (use -skipfailures to skip errors)

Since the two didnt agree on what 3857 was, I tried 4326.  Here are the 
steps that finally got it to work.


In ArcCatalog:
  reproject WCWebDataCC.gdb to 4326 and save as junk.gdb
  batch convert junk.gdb to shapefile

ogr2ogr  shapefiles to PostGIS ( includes -t_srs EPSG:3857)

Which gives us, finally:

http://testmaps.camavision.com/map/washingtonmn?pin=16.028.21.11.0039


-Andy


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

Re: [postgis-users] no .bat in windows zip installers

[Paragon Corporation]

Remi,
That was intentional.  The main reason is that with windows systems being
security paranoid, the copy would often fail and it would be hard to see
looking at a batch script console.
 
Also now that we have CREATE EXTENSION it was no longer an issue trying to
find the scripts to run, which was the main reason for the batch script.
 
Did you find it useful?  If so I can put them back.
 
Thanks,
Regina
http://www.postgis.us
 

  _  

From: postgis-users-boun...@lists.osgeo.org
[mailto:postgis-users-boun...@lists.osgeo.org] On Behalf Of Rémi Cura
Sent: Wednesday, November 12, 2014 11:41 AM
To: PostGIS Users Discussion
Subject: [postgis-users] no .bat in windows zip installers


Hey everybody.

The 2 bat files
makepostgisdb_using_extensions.bat

and
makepostgisdb.bat


seems to have vanished from the zip release file for version newer than
2.1.1 (postgis-bundle-pg93x64-2.1.1)


I'm I missing something?

thanks,

cheers,

Rémi-C


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