A Simple Named Pipes Solution for Autodesk Map3d

Author: Jonio, Dennis

I have recently decided to put together a minimalist IPC namedpipes application. I just could not think of something simplier than what I have here. This is like using a 747 jetliner to commute cross town to work but it does illustrate the ease. It is a complete, zipped up, Visual Studio 2005 solution with the entire source that I have outlined in other posts. To reiterate I use Map3d 2008 and have not tested this against vanilla AutoCAD. You will have to tell me if it works or not. I have no dependences on Map3d that I can think of.

The NETLOADable dll is, you guessed it, IPCSimple.dll. Load it up and commandline: doit. The “DataBridge” form is minimized at startup.

Startup “ClientBasicIO.exe” it is pretty obvious what to do from this point.

Most of what is happening I consider pretty much to be “boilerplate”, again thanks to Ivan Latunov. My particular implementation of serializing/de-serializing the datasets can easily be changed to support whatever construction you like. Sending a text string for “SendStringToExecute” is really kind’a sort’a silly but, like I said, I could not think of anything simpler.

At this point it is up to your imaginations as to how this can work for you. …enjoy!

You can download the solution here: http://tf-net.googlecode.com/files/IPCSimple.zip

Org.OpenGIS.GeoAPI Revisited - Part I

Author: Sestic, Maksim

I've been thinking of starting this article by lamenting on current state of the available managed OGC's GeoAPI interface implementations, but I won't :-) If you're reading this - you have probably already hit their limitations. I'm talking about GeoAPI interface ports here (a la GeoAPI.NET), not concrete implementations (i.e. NetTopologySuite, SharpMap or Proj.NET).

Not having common managed interface library makes things a lot harder for GIS developers. Present one(s) won't help you much either - most of them got way out of synch when compared to their Java-based raw model maintaned by OGC. In the meantime, Microsoft's .NET Framework itself evolved a lot, etc. To cut the long story short, my idea was to start managed GeoAPI interfaces from scratch, based on present GeoAPI 2.1.1 interfaces specification - but not by simply jumping into it...

Naming Conventions

Lets start with something "obvious" - naming conventions used in Java and .NET. For example: org.opengis.geometry namespace becomes Org.OpenGIS.Geometry namespace in .NET. Both camel-case and abbreviation rules apply, starting letter always capitalized.

When it comes to interface names, since it's mostly about them, each Java class pertaining to an interface gets an "I" prefix. For example: Precision interface becomes IPrecision in .NET.

Naming and Type Conventions

Java Get/Set functions become Properties. That is - ReadOnly properties for explicit getter functions, or WriteOnly properties for explicit setter functions. Also, get/set prefix gets stripped from resulting property name, always starting with a capital letter. For example:

Function getLength() As Double

becomes:

ReadOnly Property Length() As Double

Also:

Function getLength() As Double
Sub setLength(d As Double)

method pair becomes:

Property Length() As Double

So, when Java function becomes .NET property, and when it simply remains a method - beyond getter/setter rules stated above? It depends on overall method semantics; what it actually means to hosting class/object. For example:

Function setLength(d As Double)

when alone in a class, becomes:

WriteOnly Property Length() As Double

Because Length is a class property. But:

Function ToArray() As Double()

remains a function, since it's a method to hosting class. Sticking to described semantic rules, even parametrized functions become properties. For example:

Function getBuffer(d As Double) As IGeometry

becomes:

ReadOnly Property Buffer(ByVal d As Double) As IGeometry

since buffer is a parametrized geometric property (one of many, of course).

Type Conventions And Enumerators

Enumerated types seem rather confusing to present managed GeoAPI ports. In fact, they're simple enumerators. A good example for this is org.opengis.geometry.PrecisionType which derives from (extends) generic Java CodeList type. In .NET it becomes:

Public Enum PrecisionType

with it's members slightly changed when it comes to naming: DOUBLE becomes Double, FIXED becomes Fixed, etc. If we had a Java member named PIECEWISE_BEZIER, then it would become PiecewiseBezier in .NET. BTW, proposed notation is way closer to original ISO identifier naming rules anyways.

Type Conventions And Generics

This is the most challening part of it all. That's also why IKVM.NET won't help you much with GeoAPI in first place. Yes, it's about .NET generics and how do we use them in GeoAPI - keeping in mind future implementations. IMHO, it's very important to introduce strongly typed collections to managed GeoAPI interfaces. Alas, without knowing the nature of each interface it's close to impossible to introduce their generic counterparts properly. In other words - one needs to consult UML definition and think ahead of possible implications on implementers' side.

Ongoing Activities

You can check the current development status of managed GeoAPI library based on present GeoAPI 2.1.1 interfaces specification here: Managed OpenGIS GeoAPI Interfaces (look under SVN trunk).

Extending the IGeometryCollection type with methods provided on the HashSet(T) class

Author: Baxevanis, Nikos

Overview

As of Kim Hamilton’s post, http://blogs.msdn.com/bclteam/archive/2006/11/09/introducing-hashset-t-kim-hamilton.aspx “HashSet determines equality according to the EqualityComparer you specify, or the default EqualityComparer for the type (if you didn’t specify)”.

The IGeometryCollection type implements the IComparable(T). Using extension methods we “add” methods from the HashSet(T) class so any type that implements the IGeometryCollection appears to have instance methods such as IntersectWith, UnionWith etc.

The IGeometryCollection type implements the IComparable(T).

A HashSet(T) operation modifies the set it’s called on and doesn’t create a new set. The extension methods provided with this article return an IGeometryCollection object rather than modifying the caller set.

Implementation

“Extension methods are defined as static methods but are called by using instance method syntax. Their first parameter specifies which type the method operates on, and the parameter is preceded by the this modifier. Extension methods are only in scope when you explicitly import the namespace into your source code with a using directive.” http://msdn.microsoft.com/en-us/library/bb359438.aspx

        public static Topology.Geometries.IGeometryCollection UnionWith(this Topology.Geometries.IGeometryCollection geomCol, Topology.Geometries.IGeometryCollection otherCol)
        {
            return Operation(geomCol, otherCol, OperationType.Union);
        }

        public static Topology.Geometries.IGeometryCollection IntersectWith(this Topology.Geometries.IGeometryCollection geomCol, Topology.Geometries.IGeometryCollection otherCol)
        {
            return Operation(geomCol, otherCol, OperationType.Intersection);
        }

        private static Topology.Geometries.IGeometryCollection Operation(Topology.Geometries.IGeometryCollection geomCol, Topology.Geometries.IGeometryCollection otherCol, OperationType typeOp)
        {
            HashSet geomSet =
               new HashSet();

            foreach (Topology.Geometries.IGeometry geom in geomCol)
                geomSet.Add(geom);

            HashSet otherSet =
                new HashSet();

            foreach (Topology.Geometries.IGeometry geom in otherCol)
                otherSet.Add(geom);

            switch (typeOp)
            {
                case OperationType.Intersection:
                    geomSet.IntersectWith(otherSet);
                    break;

                case OperationType.Union:
                    geomSet.UnionWith(otherSet);
                    break;

                case OperationType.Except:
                    geomSet.ExceptWith(otherSet);
                    break;

                case OperationType.SymmetricExcept:
                    geomSet.SymmetricExceptWith(otherSet);
                    break;

                default:
                    return Topology.Geometries.GeometryCollection.Empty;
            }

            Topology.Geometries.IGeometry[] array =
               new Topology.Geometries.IGeometry[geomSet.Count];

            geomSet.CopyTo(array);

            return new Topology.Geometries.GeometryFactory().CreateGeometryCollection(array);
        }

Using the extension methods in your code

You have to add a reference to Topology.Geometries.GeometryCollectionExtensions.dll
To use the HashSet(T) operations first bring them into scope with a using Topology.Geometries.GeometryCollectionExtensions directive.

Using the HashSet(T) operations

Available for download here: http://tf-net.googlecode.com/files/GeometryCollectionExtensions-Source.zip