R: R: [postgis-users] JtsBinaryWriter and SRIDs

[P.Rizzi Ag.Mobilità Ambiente]

> But to solve your original problem, you may also copy the
> spatial_ref_sys entry in PostGIS to contain the oracle SRID (or
> vice-versa), then you have consistent SRID in your whole system:
> 
> insert into spatial_ref_sys (srid, auth_name, auth_srid, srtext,
> proj4text) SELECT 82087, 'oracle', 82087, srtext, proj4text FROM
> spatial_ref_sys WHERE srid=3003;
Yes, I know... but I don't like that, because if I have to write
into a DB "owned" by someone else, I may not be able to do that.
Or more often I will simply forgot to...
Also I have to write into Oracle too, and in that case I won't be able
to do that so, to keep me "simmetrical", I prefer not to do it here too...

> 
> > I do this for two reasons: the first is to avoid the 
> dependency on Trove,
> 
> I also dislike the dependency on Trove, but using boxed integer
> variables for the java.util HashMap key seemed to be worse.
> 
> > Note that we're talking about the JtsBinaryWriter, not the 
> JtsBinaryParser,
> > so the two SRIDs may already be different.
> 
> Okay, changing the BinaryWriter, but leaving the Parser 
> "as_is" would be
> an option.
> 
> > When you'll re-read them, the two will be equal, because 
> each geometry
> > will be built by the same factory, with the same SRID.
> 
> Yes. This would break when the parser is reworked to re-use a single
> factory, and then setSRID() on the geometries, as my code 
> initially was.
Obviously I have simpler requirements than you, so I didn't considered
(and I have no reason to) all these aspects...
Anyway the fact all geometries from the same Postgis table have
the same SRID, may be enforced, if needed, at the DB side
(with a CHECK constraint or something).
The Parser may have a similar parameter to specify the desired behaviour.

> 
> > Anyway, for the writer, the behaviour could be configurable,
> > so the default would be to use the factory SRID, but use 
> the instance SRID 
> > upon request.
> 
> Yes, that's a possibility. However, for the JDBC driver 
> extending case,
> we currently don't have any easy way to pass configuration 
> parameters to
> the Factory. The whole type extension concept is crying for beeing
> reworked, IMHO.
...yes, as I said I have simpler requirements, so I'm sorry 
I didn't considered this either...

> 
> Markus
			Bye		Paolo




AVVERTENZE AI SENSI DEL D. LGS. 196/2003  
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse.