This project is read-only.

Renaming Shapes to Geography before we release

Dec 10, 2008 at 6:08 AM
Edited Dec 10, 2008 at 6:11 AM

I had this discussion privately with Rick as part of the general cleanup for our first release.
The pins, lines and polygons we put on the map need a solid naming convention, in the beginning we modelled this off VE and called them "Shapes". The proposal is to use the naming convention from SQL Server 2008 Spatial.

This is what we have currently:
Shape, our abstract base class inherits from a Control and implements our IMapElement interface (which currently just ensures we can get to a Map instance and know if it has one)
It has:

  • ID, generated GUID
  • Description
  • Layer (ShapeLayer)
  • ShapeType
  • IsVisible
  • InView
  • ShouldBeVisible
  • InfoBoxContent
  • InfoBoxOffset
  • Refresh()
  • Intersects(bounds) abstract
  • UpdateLocation() abstract
  • HasMap from IMapElement
  • MapInstance from IMapElement

Pushpin, implements Shape

  • dependancy property AnchorPoint
  • IsSelected wired up to MouseLeftButton down

Abstract GeometryBase, implements Shape

  • Path
  • Extent
  • List<Points>
  • LineColor
  • LineThickness
  • IsClosed

Polygon, implements GeometryBase

  • FillColor

PolyLine, implements GeometryBase

The “GeometryBase” class was added as the only difference between a polygon and a polyline was the final points connected and a fill color

The fundamental issue is that I would consider only polygons and polylines to be “shapes” while I would consider a Pushpin (more conventionally known as a Point) to be a geometry as well.

The proposal is to use the naming convention from SQL Server 2008 Spatial.

SQL has Geometry for planer data and Geography for the Earth, 4326 to be specific.

Within Geography we have:

  • Point
  • MultiPoint
  • LineString
  • MultiLineString
  • Polygon
  • MultiPolygon

Although it stores the data in an internal binary format it can communicate in WKB (faster and smaller) and WKT.

So rather then have another proprietary naming system and structure lets support WKB, WKT and follow the lead from SQL 2008.

“Shape” would become “Geography”

I can see two ways to implement the actual objects, classes for each with their own specific properties like we have at the moment. Or we just have an enum “GeographyType” and they are all simply Geography with a different GeographyType, I prefer this.

The benifit of this is if we support things like UNION, INTERSECTION, BUFFER etc this type will change, if you buffer a Point by 10m it becomes a Polygon, if you Union 2 non overlaping Polygons they become a MultiPolygon etc.

If the SQL team ever release a Silverlight DLL for all there existing functionality (currently only full .net) we could leverage this. If we support WKB then it will become very easy to transmit and support all this server side and store in a SQL Database.

The only downside I see is we would have properties like linecolor and fillcolor that are not applicable to a point - is this a big deal?

This is a pretty major change, we need to do this before we release. Let me know what you think, I’m already prototyping the changes.

Dec 10, 2008 at 10:27 AM
First i will like to welcome all, i will be following this project and if possible helping it's development.

As for the issues that the post focus i have a few considerations most of all based on my experience.

1. WKB is defenetly the way to go, it is a standard and no one should be inventing new data formats wen standards exist.

2. As for the namingo convention, the suggested is ok. Microsoft has clearly named their objects using the OGC simple features standard, and that is once again the way to do it. I strongly suggest that all the classes should implement the corresponding OCG interface.

3. For the last one i left the only point were i clearly dissagree. Having geometries changing their time is not a good thing. For the sugested example, a 10m buffer on a Point must return a new Polygon. It doesn't make sense to have geometries that can change. For me geometries are all read only, you create a polygon, and later if you whant to add one inner ring in it, you should create a new polygon based on the first and adding the inner ring. This is the way that makes sense for me.

These are some advantages of having readonly geometries :
It enables the library to cache computed values (like area, geometry simplicity and stufs that can be very time and cpu consuming).
The geometry operators (union, intersection, buffer...) can all be coded as functors. They receive geometries as input and they output the result. Normaly this is the way that operators are implemented, this means that the project can rely on 3rd party tools for geometry operations.
Dec 10, 2008 at 1:01 PM

Thanks.  I think you make a good case for geometric operations being immutable.  This is also consistence with the few spatial libraries I have viewed.  Operations like Union, Reduce, etc always seem to return a new geometry.  I think this approach also would have an additional benefit.  With a Point will always be a Point, we could remove our dependency on the “ShapeType” value.  Thus removing the chance of a bug due to someone forgetting to set  a type enum property.  A type check such as “obj is Point” is preferable to our current approach of “obj.ShapeType == ShapeType.Point”.   

Dec 10, 2008 at 2:08 PM
I stand corrected, the operations do indeed create a new instance. Thanks for you input.

Pedro is the author of An Open Source GIS Engine for the .NET Framework. The project defines it's shapes as "geometry" and includes esssentially the classes I listed with full support for WKB, WKT and ESRI shapefiles. With Pedro's permission I'd like to reuse the great work from his project as a guide for what we need to do here. I have a few questions to begin.

1. Is it important for us to support a "Spatial Reference" considering the standard for the mapping we support is Mecator only? Is this something we can add later if needed or should it be there from the beginning? You have a very clean implimentation from what I can see in your code but is this over complicated for what we need?

2. Is SQL Server 2008 using the term "Geography" for good reason or simply becouse they are using "Geometry" for something else. What should we use here considering we will never need both? Geomentry or Geography?

3. Our shapes contain rendering logic and properties, eg unique ID, visibility, linecolor, infobox popup events and control etc. Considering we are a visualisation tool is it appropriate include this in these classes? What structure would you recommend? For example does the BaseGeometry inherit from a Control and impliment these?

4. We have a concept of Layers which is quite important. I assume a Layer will simply contain a List<IGeometry>? Did you use layers in your project?

Dec 10, 2008 at 3:15 PM
Vote for Pedro.  Welcome to our project.  Your comments have a lot of weight as you obviously have much experience in this area. Thanks for you reference to the OGC site.  This will be a useful reference.

Comment on Pont 3:  Soul.  I think we need to endeavor to try to keep as much visualization separated from our objects.  We've taken the first step by making our "Geometry" classes templatable, but some cleanup still remains.  The InfoBox is a great example.  This is a good "How To" sample reference, but is too implementation specific to be in the core DeepEarth project.  Anyone who would seriously use a callout would create their own.  Similarly to how DevPins which also have call out boxes are not in the core project.  I propose we need a standard to keep visual items beyond Default Templates in the Prototype and not in the core DeepEarth project.

Dec 10, 2008 at 4:08 PM
I second conformance!

Yes, this is a visualization tool, but as soon as it crosses the path of true 'geospatial' folks, they will want to add CAD, Oracle, ESRI and most importantly WKT geometry to it.  I think that implementing the OGC standards is a must.  Microsoft did do it to a point in SQL Server 2008, but that's SFA spec, DE should be sure to cover both the SFA spec and conform to the geometry specs as well.  A good example of this is PostGIS's Udig ( and the Carbon Portal (

I vote to stay away from "Geography" as a type and stick with the OGC's Geometry.  Everything should inherit from the abstract Geometry base class (interface model of course, 'IGeometry'),

Geometry SHOULD NOT be immutable at all!  Real-world objects that are tracked with geometry are inherently dynamic and their binary representations should be as well.  Here's the Object Model diagram and spec from the OGC's SFA spec that I think should be implemented:

Comments on Soul's questions:
1.  Yes, a spatial reference is a must, there are already issues with this and the Transverse Mercator projection is not the end-all.  The spatial reference should conform to the OGC and be completely independent of the geometry.
2.  Stated above, Geography is just a MS term, Geometry is more conformant.
3.  I propose a graphic's class that implements a pure WPF/Silverlight interface.  There is way more than enough power in the .NET framework to handle all graphical representations (i.e. System.Drawing) and that would be the smartest thing to do in my opinion.  This approach has worked very well for the existing packages out there and I've personally seen it succeed on my projects too.
4.  Vote for layers.  I propose an ILayer interface that can ONLY have one geometry type (i.e. point, line, poly, multi-point) per layer.  That will keep things clean and conformant to the OGC as well. 

12 more cents.

Dec 10, 2008 at 5:09 PM
Edited Dec 10, 2008 at 5:20 PM

As for the object model, i have to say that is a standard GIS object model based on the OCG Simple Feature Specification (missing only the SpatialReference part). I agree with the model, and it is also very similar to the one that was in SpatialSharp (wich is now a dead project as i'm the only member).

Also complying with OGC standard is the Imutability of the geometry object. If you take a deep look in the operators you will that they all return a new geometry. This i think is an important part, as developing geometry libraries is a very time consuming task, and this project should best stay by choosing one from the market.

As for the layers concept, they make sense. Normaly a layer is a set of heterogenous data. There should be 2 types of diferent layers the Spatial layers and the Raster layers.

Spatial layers store spatial data. The geometries in a spatial must have the same type and the same SpatialReference.

One more, as pointed by RoadWarior, (obj is Point) is the way to go... better the way to go is (obj is IPoint) one should always try to code against interfaces. Doing so, it would be simpler for one to use is one geometry objects, he just need to implement the correct interface.
Dec 10, 2008 at 5:18 PM
Now let me answer to oulsolutions,

1. Spatial References is a must. To develop a serious visualizer there's no way to avoid spatial references and geometry transformations.
Why? well do you realize that here in Portugal we use 5 coordinate systems to represent our data (1 for main land, 3 for the Azores, 1 for Madeira). So to be able to present (at the same time) data from these 3 regions you must tranform the coordinates.

2. skulavik as it, Geometry is clearly a more used tearm. I think geography is just the MS way to be different.

3. As for rendering, my approach as always been to separate the things. In spatialSharp I've created the IRenderer interface. Basically a rendere is capable of represent a geometry in a certain mean (WPF, JPEG or something like that).

4. I've discussed layer briefly in my previous post.
Dec 10, 2008 at 6:10 PM
I think that best thing to do is to avoid all of the layer, geometry, and other GIS stuff, especially the mutability of geometry and its associated parts and leverage the CLR types that are given to us by SQL Server and those alone:


That is a nightmare that's not worth tackling and it's been done already.  In short, I agree with Pedro that we need to use what's out there and minimize or eliminate the need to recreate geometry libraries.

Where geometries change and need to be manipulated in order to be added to a layer (which should be dependent upon the UI of choice i.e. Yahoo, VE, etc.) then use that UIs implementation of points, lines, and polys.
Dec 10, 2008 at 6:34 PM

This is really a great discussion.  Glad to have all this great interest.  We must be doing something right.

For DeepEarth V2, I am sure we will have much more geometry features, so it is really important that we get the foundation right.  We should definitely evaluate if we can leverage another library in Version 2.  For now (DeepEarth V1), we are just trying to conform our Silverlight types to an accepted naming standard.  Even while may be able to leverage this or other libraries for their operations, we still need templatable Silverlight types in DeepEarth.  Given that,, it is best that we don’t try to define our own standard naming, but look to a commonly accepted one such as OCG.    

Dec 11, 2008 at 1:10 AM
Unfortunatly we can't use the SQL 2008 dlls as we don't have a version or source to compile against Silverlight, Even if we did at 450KB it is a little huge.

Rick has taken on the task to rename/structure the project for the Version 1 release next week. At this stage it is important to get this part right but we don't need all the functionlaity implimented. I'd love for Skulavik and Pedro to provide feedback to Rick when he makes the changes later in the week and start planning / discussions on how and what we can impliment in the next version.

I agree with Rick, Version 1 is about a solid platform, the next version I think will be all about data. This will start next week and there will be many ways to contribute.
Dec 11, 2008 at 9:36 AM
Guy's i think that mostly there are two paths, and one should decide where to go.

1. Define this project as a visualizer and visualizer only. Going by this path, probably the need for a geometry lib is minor. And the focus should be in supporting data from multiple sources such as WMS servers.

2. Take the visualizer one step forward and support editing functions. This will require more geometry work and therefore a deeper geometry library. There are a few ports of the Java Topology Suit (witch is a good open source geometry library) to the .NET and also several other geometry libraries that can be used. As for the overhead, i don't think that a geometry library will ever be very small in terms o KBs.

As for now i do think that version 1 is on the right path, i confess that i'm quiet impressed with the demo. As for the future road map, i think that the team must define in a clear way what path should the project take, and then take the necessery actions to fullfil the needed requests.
Dec 11, 2008 at 4:03 PM
I'll look forward to working with Rick and Pedro to get the renaming set for V1.  I agree fully, worry about the data later.  The KISS prinicpal should apply here and we don't need to re-write another web-GIS that allows people to edit points, lines, and polys.  The keys here are performance, simplicity and avoiding a complicated product.  I'm looking forward to it.....
Dec 12, 2008 at 12:49 AM
Initially I thought DeepEarth would just be a data visualizer. But Silverlight offers a great and powerful UX. We could easily add geometry editing capabilities and export capabilities in many formats.
We're all in agreement that we should take a staged approach with this. Breaking up the functionality into smaller tasks will allow us to divide the work and fit in with the spare time that we each can commit to the project.

Let explore what sort of functionality DeepEarth could have and won't simply work. For example I can't ever imagine a full blown ArcGIS experience but some simple drawing tools seems like a no brainer.
It maybe useful to look at these as user cases for example some functionaity:

  1. Display a set of pushpins on the map, allow the user to drag the pins to a new location and edit content of infobox, data updates are serialised sent to WCF service.
  2. User selects a drawing mode and can draw points, lines and polygons. Saved to server.
  3. A set of geometry is shown on the map, the user draws a polygon, the intersecting geometries are selected.
  4. A set of geometry is shown on the map, the user draws a polygon, the intersecting geometries are merged into one new geometry.

The user case could be: A news website want to be able to create an interactive map to acompany stories. They have a many layers of exisiting assests. They add the specific information the want, add generic layers, choose exactly what they want to show and publish as a map.

Dec 12, 2008 at 8:47 AM
Edited Dec 12, 2008 at 8:49 AM
From my recent experience, i do think that supporting drawing functionality may be a way to distinguish the project from the others.
This although arises a few subjects. We will need to develop a server part of the project to handle the serialization of data and stuffs like that.

For now i think that the most important would be to agree in the main direction, are we only going for a visualizer or do we want to have drawing capabilities ?

After deciding where to go, i think that a Product road map should be developed. For a product road map I mean a document where future requirements are described (for all the requirements the product release version should also be included). This would be an always opened document and would suffer several changes during the project development. I consider this to be a very important part of a Product development as it would be a guide to the ones that contribute and also for the ones that use or are planing to use the Product.
Dec 14, 2008 at 10:35 PM
Great to have you guys aboard.  We will plan to have a Skype call for V2 soon after our first release.  We could get a dialog started on features and develop the product roadmap for V2.  Additionally, we need to establish some guiding principals as well.  Something we can use as a litmus test for whether a featue is in or out. 
Dec 15, 2008 at 2:16 PM
I think that the refactoring/renaming that you did looks pretty darn good Rick.  Let us know when you're ready for a Skype call.