- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Fri, 9 Sep 2016 13:29:04 +0200
- To: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <CAFVDz43hH50nermvCq1FeHpFphxeUHhU=CZHP4iOxOENpGV8fA@mail.gmail.com>
Hello, What could be wrong with simply expressing spatial resolution as a distance in CRS units? It would be a number that is easy to interpret, process and compare. Regards, Frans On 7 September 2016 at 01:16, Rob Atkinson <rob@metalinkage.com.au> wrote: > I have a bad feeling about this - describing zoom levels clearly enough so > that MyZoom can be compared with YourZoom means a description of CRS and > precision, and maybe rendering technology, deduplication and labelling. > There are lots of datasets with something similar built in - but not a lot > of evidence people are trying to standardise such terms. > > My feeling is that we should leave the datatype of precision/resolution > open - then people can use a zoom level categorisation as an option. I > would suggest that BP is that the coordinate precision can be identified > _if present_ and described in units relevant to the CRS (perhaps the term > should be "spatial resolution" perhaps as grid tesselations such as DGGS or > what3wordsmay be used instead of coordinates for spatial positioning). > > thus its fine to have something like > geo-core:resolution :zoom1; > :zoom1 a myns:ZoomLevel ; > myns:ZoomLevel a wms:DisplayZoomConcept; > zoom1 wms:nominalDisplayScale 50000; > zoom1 myns:nearestHigherOrderZoomObjectDistance 1000; > > i.e. i think Zoom semantics need to defined in some operational context, > then instantiated with parameters - but I dont think we could specify > canonical properties easily - so it needs to be bound to a more general > property - which probably does need to be canonical (or declared as a > subProperty of the canonical Property, to allow backwards compatibility > with existing data) > > Rob > > > > On Wed, 7 Sep 2016 at 07:09 Byron Cochrane <bcochrane@linz.govt.nz> wrote: > >> Hi Jeremy, >> >> >> >> I think that zoom level could be used in a variety of context, but >> primarily to state the resolution of the dataset. Instead of stating the >> resolution (scale at which the data was designed to be used) as 1:50000, a >> data publisher could state the data (say a coastline) as meant to be used >> at Zoom level 13. A more detailed version of the coastline could be stated >> as being Zoom Level 18. >> >> >> >> This approach could possible be used for stating some fuzzy boundary type >> data, say the American West. These are often represented as label points >> since a polygon would be misleading. A bounding box or radius could be >> derived based on some statement of zoom level appropriate to the data. In >> this case, American West is a broad area, so zoom level 3 or 4 might be >> appropriate for this spatial object. This would be a statement of >> vagueness in this case. >> >> >> >> I would change your statement slightly from “stating the extent of a >> spatial thing based on the first zoom-level that it would be resolved at” >> to “stating the extent of a spatial thing based on the first zoom-level >> that it was designed to be used at.” I don’t believe there is currently >> any support in existing metadata standards or tools for zoom levels. >> >> >> >> Just throwing this out there. My feeling is that Zoom Levels are a more >> accessible concept to the non-gis folk. It is something they use >> frequently and is tangible to them. Definitely needs more work. But there >> is a near consensus it seems on what these zoom levels are so we have a >> good start to build on. >> >> >> >> Cheers, >> >> Byron >> >> >> >> *From:* Jeremy Tandy [mailto:jeremy.tandy@gmail.com] >> *Sent:* Tuesday, 6 September 2016 8:35 a.m. >> *To:* Byron Cochrane; Simon.Cox@csiro.au; jlieberman@tumblingwalls.com >> *Cc:* eparsons@google.com; public-sdw-wg@w3.org >> *Subject:* Re: Fuzzy Spatial relations - was RE: Spatial relations - was >> RE: Request for help: BP 9 "How to describe relative positions" >> >> >> >> Hi Byron- apologies for missing this at the end of last week. I think >> that this is an interesting concept; to use resolution to describe spatial >> things >> >> I summarise as "stating the extent of a spatial thing based on the first >> zoom-level that it would be resolved at". Is this a reasonable >> approximation? >> >> Of course, what you display on a map tile at a given resolution is >> somewhat subjective - it clearly has to be bigger than a single pixel, and >> big enough so that it is not cluttered with other spatial things of the >> same type. Have you come across any guidance for what size of spatial thing >> should be displayed at each zoom level? (more so than the few items in the >> table you included in your email) ... Is size even the right measure? For >> example - why is Aukland the first city to appear when zooming in on NZ? >> It's bigger by population, but it's not the capital city ... >> >> Jeremy >> >> On Fri, 2 Sep 2016 at 00:00, Byron Cochrane <bcochrane@linz.govt.nz> >> wrote: >> >> Probably going off on a tangent here, but it is related….. >> >> >> >> I see this discussion of vagueness in spatial relations in many aspects >> as being related to the concept of Spatial Resolution (to use the >> terminology from ISO 19139). We have talked a bit about the related issues >> of precision and accuracy but not much about scale – what level of spatial >> detail the data was designed to be used at. To illustrate this, what is >> the bounding box of a single point? That depends on the Spatial >> Resolution. You could have a point feature for “American West” and >> describe it with a large bounding geometry based on a 1:250 million scale >> factor. >> >> >> >> Currently Spatial Resolution is stated in the geo community as a Map >> Scale factor, e.g. 1:50:000. I see this as a terribly outmoded conceptual >> approach to stating the spatial resolution of an object. It is meaningless >> because of differences of display dimensions makes stating scale in such a >> way inaccurate at best and hard to understand. Concepts such as large >> scale and small scale are also confusing to the non-specialist. These >> people don’t generally work with data this way. What they are more >> familiar with is Zoom Levels. >> >> >> >> If we could talk about spatial resolution in terms of Zoom Levels, I >> think we could reach a broader audience of data users. Luckily for us, >> there seems to be close to a consensus in modern web mapping tools on what >> these level should be. There are generally about 20 levels. The best >> compilation and description of these that I have found comes from OSM shown >> below. http://wiki.openstreetmap.org/wiki/Zoom_levels I like this >> approach because it gives us a handle as to how we talk about spatial >> vagueness, scale, accuracy and precision with a handy heuristic. While >> this does not cover all the issues of Fuzzy spatial relations as raised by >> Jeremy, I think it is a useful approach. Unfortunately, this standard does >> not exist currently, nor do mechanisms in support this exist in tools such >> as metadata standards. So *if people agree *this is a useful idea, >> where do we go with it? >> >> >> >> Or am I way off base and is this not a path worth pursuing? >> >> >> >> *Level* >> >> *Degree* >> >> *Area* >> >> *m / pixel* >> >> *~Scale* >> >> *# Tiles* >> >> 0 >> >> 360 >> >> whole world >> >> 156,412 >> >> 1:500 million >> >> 1 >> >> 1 >> >> 180 >> >> 78,206 >> >> 1:250 million >> >> 4 >> >> 2 >> >> 90 >> >> 39,103 >> >> 1:150 million >> >> 16 >> >> 3 >> >> 45 >> >> 19,551 >> >> 1:70 million >> >> 64 >> >> 4 >> >> 22.5 >> >> 9,776 >> >> 1:35 million >> >> 256 >> >> 5 >> >> 11.25 >> >> 4,888 >> >> 1:15 million >> >> 1,024 >> >> 6 >> >> 5.625 >> >> 2,444 >> >> 1:10 million >> >> 4,096 >> >> 7 >> >> 2.813 >> >> 1,222 >> >> 1:4 million >> >> 16,384 >> >> 8 >> >> 1.406 >> >> 610.984 >> >> 1:2 million >> >> 65,536 >> >> 9 >> >> 0.703 >> >> wide area >> >> 305.492 >> >> 1:1 million >> >> 262,144 >> >> 10 >> >> 0.352 >> >> 152.746 >> >> 1:500,000 >> >> 1,048,576 >> >> 11 >> >> 0.176 >> >> area >> >> 76.373 >> >> 1:250,000 >> >> 4,194,304 >> >> 12 >> >> 0.088 >> >> 38.187 >> >> 1:150,000 >> >> 16,777,216 >> >> 13 >> >> 0.044 >> >> village or town >> >> 19.093 >> >> 1:70,000 >> >> 67,108,864 >> >> 14 >> >> 0.022 >> >> 9.547 >> >> 1:35,000 >> >> 268,435,456 >> >> 15 >> >> 0.011 >> >> 4.773 >> >> 1:15,000 >> >> 1,073,741,824 >> >> 16 >> >> 0.005 >> >> small road >> >> 2.387 >> >> 1:8,000 >> >> 4,294,967,296 >> >> 17 >> >> 0.003 >> >> 1.193 >> >> 1:4,000 >> >> 17,179,869,184 >> >> 18 >> >> 0.001 >> >> 0.596 >> >> 1:2,000 >> >> 68,719,476,736 >> >> 19 >> >> 0.0005 >> >> 0.298 >> >> 1:1,000 >> >> 274,877,906,944 >> >> >> >> Byron >> >> >> >> >> >> *From:* Jeremy Tandy [mailto:jeremy.tandy@gmail.com] >> *Sent:* Friday, 2 September 2016 4:28 a.m. >> *To:* Simon.Cox@csiro.au; jlieberman@tumblingwalls.com >> *Cc:* eparsons@google.com; public-sdw-wg@w3.org >> *Subject:* Re: Spatial relations - was RE: Request for help: BP 9 "How >> to describe relative positions" >> >> >> >> @simon - that's perfect. Do you agree that it would be a good idea to get >> these registered as Link Relation types on the IANA registry? >> >> >> >> I think the definitions are also in your document [1] for input into the >> registry ... >> >> >> >> Jeremy >> >> >> >> [1]: https://www.w3.org/TR/owl-time/#vocabulary >> >> >> >> On Thu, 1 Sep 2016 at 08:56 <Simon.Cox@csiro.au> wrote: >> >> For temporal relations, I re-drafted a diagram from one of Allen’s >> papers: >> >> https://www.w3.org/TR/owl-time/images/IntervalRelations.png >> >> >> >> *From:* Jeremy Tandy [mailto:jeremy.tandy@gmail.com] >> *Sent:* Wednesday, 31 August 2016 9:43 PM >> *To:* Joshua Lieberman <jlieberman@tumblingwalls.com>; Cox, Simon (L&W, >> Clayton) <Simon.Cox@csiro.au> >> *Cc:* eparsons@google.com; public-sdw-wg@w3.org >> *Subject:* Re: Request for help: BP 9 "How to describe relative >> positions" >> >> >> >> *[…]* >> Finally, I also note that I still need help on the "spatial relations" >> topic that was second in my original email. More help required please. >> >> >> Jeremy >> >> >> >> *[…]* >> >> On Wed, 31 Aug 2016 at 10:26 Jeremy Tandy <jeremy.tandy@gmail.com> wrote: >> >> Hi- >> >> >> >> BP doc section § 10.5.1 "Describing location" [1] is where we intend to >> provide all the guidance that explains how you should encode location >> information in a web-friendly way. >> >> >> >> This includes BP 8 "Provide geometries on the Web in a usable way" [2] >> and BP 9 "How to describe relative positions" [3]. >> >> >> >> (I think it's likely that we will also need a BP to help people choose >> the right CRS too ...) >> >> >> >> We editors envisage BP 9 covering: >> >> >> >> (1) Linear referencing >> >> (2) Use of spatial relations [4] >> >> >> >> ... >> >> >> >> *[…]* >> >> >> >> (2) >> >> We also want to demonstrate how spatial relations are used. There are >> obvious examples of topological relationships such as "this administrative >> unit _touches_ that administrative unit" (or contains etc.). >> >> >> >> I recall that we were going to get the set of topological relationships >> added to the IANA Link Relations registry [7]. I am not even sure which set >> of topological relations we should be recommending? GeoSPARQL has me >> somewhat confused with "Simple Features Relation", "Egenhofer Relation" and >> "RCC8 Relation". Then there's D9-EIM too ... >> >> >> >> Can someone provide me some worked examples using the preferred set of >> topological relationships? >> >> >> >> We also need to illustrate use of _directional_ (e.g. "left", "in front >> of" and "astern") and _distance_ relations (e.g. "at", "nearby" and "far >> away"). I don't know of any formalised vocabulary for expressing these >> things. If there is one, should we be seeking to add these to the IANA Link >> Relations registry too? >> >> >> >> Again, worked examples requested! If you can related them to an urban >> environment / flooding scenario all the better. (e.g. someone might assert >> "the flooding is near my house") >> >> >> >> Finally, we also need to show people how to express "fuzzy" spatial >> things. Examples we have elsewhere in the BP doc are "the American West" >> and "Renaissance Italy". These are spatial things were there is not general >> agreement about the exact geographic extent, so it is not possible to use a >> geometry to describe it. What is the best way to describe things like this? >> Should we use spatial relations e.g. "downtown" _contains_ city districts >> A, C, D, and G (because "everyone" agrees this) - but we're not saying it's >> exact geometry because it's a colloquial term used by citizens of our >> fictional Nieuwhaven. >> >> >> >> Again, I'd like to see a worked example. >> >> >> >> ... >> >> >> >> There's a lot of questions wrapped up in this email. I'm looking for help >> to resolve them ... preferably with someone in the WG taking the lead to >> coordinate a response. >> >> >> >> I'm also aware that we need to avoid an RDF bias, so it would be good to >> have examples in other formats too. >> >> >> >> Volunteers, please step forward! >> >> >> >> Thanks in advance. Jeremy >> >> >> >> [1]: http://w3c.github.io/sdw/bp/#bp-expr-geo >> >> [2]: http://w3c.github.io/sdw/bp/#describe-geometry >> >> [3]: http://w3c.github.io/sdw/bp/#relative-position >> >> [4]: http://w3c.github.io/sdw/bp/#spatial-relations >> >> [5]: https://github.com/ISO-TC211/HMMG >> >> [6]: http://inspire.ec.europa.eu/documents/Data_Specificatio >> ns/INSPIRE_DataSpecification_TN_v3.2.pdf >> >> [7]: http://www.iana.org/assignments/link-relations/link-relations.xhtml >> >> >> -- >> >> *Ed Parsons *FRGS >> Geospatial Technologist, Google >> >> Google Voice +44 (0)20 7881 4501 >> www.edparsons.com @edparsons >> >> >> ------------------------------ >> >> This message contains information, which may be in confidence and may be >> subject to legal privilege. If you are not the intended recipient, you must >> not peruse, use, disseminate, distribute or copy this message. If you have >> received this message in error, please notify us immediately (Phone 0800 >> 665 463 or info@linz.govt.nz) and destroy the original message. LINZ >> accepts no responsibility for changes to this email, or for any >> attachments, after its transmission from LINZ. Thank You. >> >>
Received on Friday, 9 September 2016 11:29:38 UTC