How to instantiate IGeometryFactory's

[GoogleCodeExporter]

Gennaddiy raised an interesting question on issue 97:
How are geometry factories usually instantiated?

This is particulary interesting in regard to geometry readers / converters, 
since they are supposed to have a factory.

JTS does not have IGeometryFactory interface so the issue does not arise since 
it simply instantiates a new GeometryFactory whenever needed. If, e.g. 
WKBReader should read a geometry whose SRID value does not match that of the 
assigned geometry factory, the assigned one is simply replaced. 

As we are dealing with IGeometryFactory interface in NTS.IO that is not 
applicable (I doubt that it is the smartes solution, anyway). 

The problem goes further: Shouldn't changing the SRID value result in assigning 
a new GeometryFactory? JTS does not handle those cases. It is possible to 
change the SRID value, while it is impossible to change the GeometryFactory.

I'd suggest to use some IOC pattern build with CommonServiceLocator
http://commonservicelocator.codeplex.com

That way we'd have a static ServiceLocator object throughout NTS.IO, that has a 
means of providing IGeometryFactory, ICoordinateSequenceFactory and 
IPrecisionModel.

Code would look somehow like this:

var pmType = PrecisionModels.SingleFloating;
var pm = ServiceLocator.GetInstance<IPrecisionModel>();
Debug.Assert(pm.PrecisionModelType == pmType);
var csf = ServiceLocator.GetInstance<ICoordinateSequenceFactory>();
int srid = 4326;
var gf = ServiceLocator.GetInstance<IGeometryFactory>();
Debug.Assert(gf.SRID == 4326);
srid = 31466;
var gf = ServiceLocator.GetInstance<IGeometryFactory>();
Debug.Assert(gf.SRID == 31466);

CommonServiceLocator is wrapped/implemented by a broad range of IOC Containers 
(see url above). Perhaps a lean default GeoAPI implementation would help.

Any thoughts?

Original issue reported on code.google.com by felix.ob...@netcologne.de on 5 Nov 2011 at 9:06

[GoogleCodeExporter]

Sorry, a typo:
All calls to 
  ServiceLocator.GetInstance<..>();
should be
  ServiceLocator.Current.GetInstance<..>();

Original comment by felix.ob...@netcologne.de on 5 Nov 2011 at 9:12

[GoogleCodeExporter]

I just learned -the hard way- that this approach won't work, due to the 
flexibility we need on creating geometry factories. We would need a new 
interface, that basically provides the GeometryFactory constructor options as 
Create functions.

That could be resolved using CommonServiceLocator.

Original comment by felix.ob...@netcologne.de on 5 Nov 2011 at 11:38

• Added labels: Priority-Low
• Removed labels: Priority-High

[GoogleCodeExporter]

What if simply the IGeometryFactoryFactory interface is provided to the 
readers/writers when created: i.e as constructor parameters? I strongly suggest 
to not use CommonServiceLocators or IoC containers inside NTS library, i.e: as 
required features for the library to work.
It's a developer choice to use ServiceLocators or other stuff, library should 
be as easy as possible.
My2Cents.

Original comment by diegogu...@gmail.com on 6 Nov 2011 at 10:16

[GoogleCodeExporter]

I agree with diegoguidi. Have a simple base functionality in NTS that you can 
then extend but keep extensions separate.

Original comment by johan.li...@astando.se on 7 Nov 2011 at 7:43