[postgis-users] Suspect shape(s) -- multipolygons and largeloadfiles

Tue Oct 28 16:34:46 PST 2003

Mmm ... the shape breaks the Informix shape unloader ... a null record for the shape, I think. Arcview won't even see the file.

I manually inserted it into postgres with some cut-and-paste, deleted the record from my load sql file and am now done with that one table.

Just for grins I unloaded the resulting table with the pgsql2shp program (latest and greatest as of yesterday) and it seems to have unloaded everything ok. When I open the resulting shpae file in arcview it too shows only this huge "L" which it says is the suspect shape. All the other entries in the shape file are not visible (occluded by this one, I think, or it has to zoom so far to see this that it can't show the others).

When I get a chance I'll have another go at making a shape file of just this shape and send it ... may violate some basic logic, but as I say, both Informix spatial blade and postgis seem to be happy with it.

Greg W.

-----Original Message-----
From: Paul Ramsey [mailto:pramsey at refractions.net]
Sent: Tuesday, October 28, 2003 7:59 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Suspect shape(s) -- multipolygons and
largeloadfiles

Make us a shape file with just that geometry in it, and we might be  
able to find out what is wrong (my money is on it being a completely  
bogus deviation from the published standard :)
P.

On Tuesday, October 28, 2003, at 12:23 AM, Gregory S. Williamson wrote:

> I acquired the latest and greatest cvs version (as of about 16:00  
> today, Pacific time) and tada! it correctly parsed my earlier  
> troublesome multiploygon geometry. Thanks for the hint!
>
> However, in the "no good deed goes unpunished" category, I have  
> another troublesome shape from the same table, a polygon (attached as  
> a text file). It has 464 points; JUMP tells me it is a "self  
> intersection" and returns it as an "L" shape.
>
> This is what the shape2pgsql generated:
>
> Insert into sid_content_cust2  
> (gid,TRACKING_ID,P_DISK_ID,P_MACHINE,B_DISK_ID,B_MACHINE,STACKING_OR,P_ 
> DIRECTORY,B_DIRECTORY,FILENAME,PROJ_KEY,COPYRIGHT,the_geom)  
> values('212528','111111','11','aserver','1','aserver','2227','/ 
> directory/','/ 
> directory','5m_st_tropez.sid','French_Lambert_II_Etendu','1',GeometryFr 
> omText('MULTIPOLYGON()',4326) );
>
> This gets:
> psql:xab:30: ERROR:  couldnt parse objects in GEOMETRY
>
> (natch)
>
> This shape may violate some rule -- Informix seems to cope with it;  
> JUMP doesn't; won't be able to try ARC stuff until tomorrow.
>
> Any (further) advice would be welcome !
>
> Thanks,
>
> Greg Williamson
> DBA
> GlobeXplorer LLC
>
>
> -----Original Message-----
> From:	strk [mailto:strk at keybit.net]
> Sent:	Mon 10/27/2003 2:09 AM
> To:	PostGIS Users Discussion
> Cc:	
> Subject:	Re: [postgis-users] Suspect shape(s) -- multipolygons and  
> large loadfiles
>
> What version of shp2pgsql are you using ?
> There have been changes in the loader, try latest CVS
> and see what happens.
>
> --strk
>
> gsw wrote:
>> Dear peoples,
>>
>> I've got to move several dozen tables of varying size (a few hundred  
>> to about 500,000 rows per table) of spatial data from Informix'  
>> spatial blade into postgres postgis. The data is well-behaved by  
>> Informix' standards. I unload using the unloadshp Informix utility  
>> which gives me shape files; I then process those with the postgres'  
>> shp2psql utility and then run the resulting sql file.
>>
>> In one file I process some 63097 records and then I get an error:
>>
>> psql:sid_content.sql:63353: ERROR:  couldnt parse objects in GEOMETRY
>>
>> The offending WKT is attached. I did a bit of cut-and-paste and tried  
>> it in the JUMP platform and I get a warning (?) in the status bar of  
>> that tool saying "Ring Self-Intersection" ... the shape seemed to be  
>> functional enough that this tool could display it.
>>
>> So a couple of questions come to mind:
>> a) what might be done about this ? (its a shape of an image file so  
>> there may limits in editing it but perhaps tweaks could be made).
>>
>> b) to find this offending record was tedious -- i ended up running  
>> the sql file with a "psql -s -f sid_content.sql" option and stepping  
>> through the 63k records. Any suggestions for a more painless method  
>> of finding offending records would be welcome. Although some largish  
>> tables have loaded without error, others have not.
>>
>> Thanks for any advice !
>>
>> Greg Williamson
>> DBA
>> GlobeXplorer LLC
>>
>>
>
>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
>
>
> <a_big_poly.txt>_______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
      Paul Ramsey
      Refractions Research
      Email: pramsey at refractions.net
      Phone: (250) 885-0632

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users