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

[P.Rizzi Ag.Mobilità Ambiente]

> Hi, Paolo,
> 
> P.Rizzi Ag.Mobilità Ambiente wrote:
> 
> >>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...
> 
> To be honest, my _personal_ requirements are pretty simple, but as
> Maintainer, I have to estimate the requirements of all other users.
Yes, obviously...

> 
> > 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).
> 
> Yes, and this is independend from the way the driver fetches his SRID,
> because the driver does not have any notion of tables at all. The SQL
> query may even process and mangle the geometry in many ways 
> without even
> looking at a table at all. :-)
Yes, now I got it. It may even be a stored procedure returning random
geometries...

> 
> > The Parser may have a similar parameter to specify the 
> desired behaviour.
> 
> Yes, that would make sense. I really wish we'd have per connection
> settings for this. Maybe we'll have to patch pgJDBC. :-)
> 
> >>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...
> 
> Well, a first step would be to make this configurable in the parser /
> writer instance, so at least those who use the parser directly can
> configure it the way they want.
Yes, this seems a good thing. Parser and Writer should be usable alone
and configurable as such. The driver will have problem configuring them,
but at least who don't use the driver won't be affected.

And to answer your message in the JTS list, you should at least remove the
use of the factory cache from the Parser and move it to the driver.
The problem is that the SRID is not known until the parser starts parsing.
So you may interpose an interface that the parser will use to ask for a
factory:
	public interface GeometryFactoryProvider {
		GeometryFactory getFactory(int srid);
	}

The parser may be constructed with an instance of this interface or it may
be set with a setter. Then inside parse() it can do, instead of:
        if (geofac == null) {
            //geofac = JtsGeometry.getFactory(srid);
		...
something like:
        if (geofac == null) {
        	geofac = provider != null ? provider.getFactory(srid) :
null;
and after that it may even do something like:
        if (geofac == null) {
        	geofac = new GeometryFactory(
        			new PrecisionModel(), 
				srid,
	
PackedCoordinateSequenceFactory.DOUBLE_FACTORY);		
		...

The driver will set the parser with something like:
	bp.setGeometryFactoryProvider(new GeometryFactoryProvider() {
		public GeometryFactory getFactory(int srid) {
			return JtsGeometry.getFactory(srid);
		}	
	});

The parser may also have a:
	setForcedSRID(int srid);
method that stores a srid to use whatever it was the one read.
So, after a geometry has been created, if this value was set it may be used
to replace the SRID of the geometry:
	geom.setSRID(forcedSRID);

Also the geofac used by parse() may be stored at the parser level, so it may
be
set only once, like this:
	setForcedFactory(aFactory);

The inside parse() it may do something like:
        if (geofac == null && forcedFactory != null ) 
		if( srid [the one read] == forcedFactory.getSRID()
			geofac = forcedFactory;

So it will use the forced factory it it has the right SRID, otherwise it
will
call provider or what else.

Client code will probably already know what SRID it uses and it will
probably
be always the same, so it may call set parser like this:
	GeometryFactory gf = new GeometryFactory(my_only_srid,...);
	bp.setGeometryFactoryProvider(new GeometryFactoryProvider() {
		public GeometryFactory getFactory(int srid) {
			return srid == gf.getSRID() ? gf : null;
		}	
	});

Or even simpler like:
	bp.setForcedFactory(new GeometryFactory(my_only_srid,...));

Maybe I elaborated too much...

> 
> And as no one spoke up here on this list, I'd even make the writer
> getting the SRID from the geometry the default, because 
> fetching it from
> the factory was an ugly (IMHO) workaround for the deprecated getSRID()
> in jts 1.6, which I expected to vanish in 1.7 instead of 
> being legalized
> again.
I have no idea of what the existing client code base is, so it's up to
you...
In the Writer I sent you, I used a parameter to say which SRID to use (geom
or factory),
but it may even be more than what's needed. For example in OraWriter (in
CVS) they now have a
setSRID() to force a single unique SRID for all the geometries written.
If it's not set they use geom.getSRID(), so the factory SRID is not used in
any case.

> 
> I'll have a look into this.
> 
> Markus
> -- 
> Markus Schaber | Logical Tracking&Tracing International AG
> Dipl. Inf.     | Software Development GIS
> 
> Fight against software patents in EU! www.ffii.org 
www.nosoftwarepatents.org

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




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.