Units for Extent

Jul 23, 2012 at 2:39 AM

I'm looking at a source that can (potentially) provide the extent in a range of units (could be degrees, could be metres, I can only know at runtime). Does the Extent in the schema have pre-assumed units (metres), or is it only ever relative to the SRS returned by the schema?

Similarly, is resolution in the schema defined in terms of SRS units per pixel?

I did have a look in the code, and didn't see anything that suggested it was anything other than SRS units, but its a lot of code, and I'm not confident of my ability to grok this much C# without a bit more familiarity.

Jul 23, 2012 at 10:28 AM

That is correct. It is SRS units.

Jul 24, 2012 at 2:58 AM

Thanks (again) Paul.

However it does raise another query (as I start to think this through a bit): does that mean that Extent instances are only sensible in the context of a SRS? So you shouldn't be able to do operations between two different Extents that aren't using the same SRS?

If so, we should probably check this, perhaps with something like:

# HG changeset patch
# User Brad Hards <bradh@frogmouth.net>
# Date 1343094731 -36000
# Node ID baca81630e8df3b8168fdd74742584098dc586e1
# Parent  99fa40b95b7533892008901cd38eab1867444217
Add SRS to Extent to ensure sane comparison

diff -r 99fa40b95b75 -r baca81630e8d BruTile/Extent.cs
--- a/BruTile/Extent.cs	Fri Jul 20 12:07:23 2012 +1000
+++ b/BruTile/Extent.cs	Tue Jul 24 11:52:11 2012 +1000
@@ -7,6 +7,7 @@
     public struct Extent
+        public string Srs { get; private set; }
         public double MinX { get; private set; }
         public double MinY { get; private set; }
         public double MaxX { get; private set; }
@@ -39,6 +40,10 @@
         public Extent Intersect(Extent other) //TODO: check how to name this method.
+            if (other.Srs != Srs)
+            {
+                throw new ArgumentException("cannot generate intersection of Extents using different Srs");
+            }
             return new Extent(
                 Math.Max(MinX, other.MinX),
                 Math.Max(MinY, other.MinY),
@@ -61,6 +66,10 @@
         public bool Intersects(Extent box)
+            if (box.Srs != Srs)
+            {
+                throw new ArgumentException("cannot test intersection of Extents using different Srs");
+            }
             return !(
                         box.MinX > MaxX ||
                         box.MaxX < MinX ||
@@ -85,6 +94,10 @@
         public bool Equals(Extent extent)
+            if (extent.Srs != Srs)
+            {
+                throw new ArgumentException("cannot test equivalence of Extents using different Srs");
+            }
             if (MinX != extent.MinX)
                 return false;

Does that look reasonable? It would obviously require some extra code in the callers before I get to the pull request stage...

Jul 24, 2012 at 11:26 AM

hi Brad, it is true that an Intersect of boxes with different Extents does not make sense. Adding an Srs though would mean that you have to use that consistently throughout the application. In some cases people do not know the SRS. Perhaps it should be allowed to make it nullable and allow Intersects where one of the two is null.

There is also the question how to represent the Srs. In many clients this is in Int32. But perhaps a String would be better, so it would allow alternative authorities besides 'EPSG:'. 

We could also leave it all the responsibility of the client app. I expect them to use their own BoundingBox's. And these could be proper OGC complient BBoxes. I am inclined to leave it as simple as it is for now. BruTile should then be wrapped inside a Layer in a client that only exposes its own proper BBoxes.

Jul 24, 2012 at 1:51 PM

btw, What are you building? A new mapping application? of do you use it as part of an existing application? What platform are you building on?


Jul 24, 2012 at 11:04 PM

I'm investigating adding support for a new offline tile source (inspired by MBTiles, but more complex) in work at the OGC.

In terms of user application, I'll probably just try to extend the existing applications to demonstrate feasibility. The interest in BruTile is standard Windows desktop at this stage, but I'm interested in the other platforms if they can be made to work. I'd like to do PCL (I haven't seen that before - interesting stuff), but I need SQLite support (in some form), so that may be a limiting factor - any suggestions gratefully received tthough.


Jul 25, 2012 at 12:04 AM
Edited Jul 25, 2012 at 12:05 AM

OGC, wow, I would love to be of help.

If the tile format needs the flexibility of WMTS there will need to be changes to the TileSchema, like adding an extent for each level. This is something I had in mind for a long time.

The BruTile PCL can be used in a desktop as is. It would be nice if we could turn MBTiles into a PCL. It has no high priority. There is already a Silverlight build, which means converting it to PCL will not be very hard. There might be some tricky parts though. The MBTiles project was built by Felix Obermaier of SharpMap.

Jul 31, 2012 at 12:26 PM

MBTiles or SQLite with BruTile PCL should be doable using Csharp-sqlite, if there were a Csharp-sqlite PCL project set up...

I raised an issue regarding that. It'd be neat to get rid of System.Data.Ersatz for MBTiles.Silverlight project.
That is probably a prerequisite for the PCL version as well.