Wikidata

Wikidata:Property proposal/bounding box

< Wikidata:Property proposal

Bounding box

edit

Bounding box west coordinates (1 of 2 pairs)

edit
   Not done
Descriptionone of two extreme points of a bounding box (SW or NW). Note the second proposal below for the 2 of 2.
Representsminimum bounding box (Q6865426)
Data typeGeographic coordinates
Domainmap (Q4006), spatial reference system (Q161779) or rather geographic coordinate system (Q22664)
ExampleAddresses and travel map of Helsinki from 1876 (Q17610148) →60.145382160146696, 24.86374620040312 (southwest / lowerleft)
Finnish national grid coordinate system (Q10542255) → 59.75, 19.24

Bounding box east coordinates (2 of 2 pairs)

edit
   Not done
Descriptionone of two extreme points of a bounding box (NE or SE)
Representsminimum bounding box (Q6865426)
Data typeGeographic coordinates
Domainmap (Q4006), spatial reference system (Q161779) or rather geographic coordinate system (Q22664)
ExampleAddresses and travel map of Helsinki from 1876 (Q17610148) → 60.19526296266577, 24.999132404114395 (northeast / upperright)
Finnish national grid coordinate system (Q10542255) → 70.09, 31.59
    • Sure. Coordinate datatype requires you to input latitude and longitude. With two statements, you'd get four coordinates. BTW, please keep the two proposals together.
      --- Jura 10:56, 14 June 2016 (UTC)[reply]
  •  Comment Perhaps it is not necessary to fix whether the box is with upperleft-lowerright or lowerleft-upperright values? / Susannaanas (talk) 13:14, 14 June 2016 (UTC)[reply]
    • It shouldn't matter. WQS can search within: mw:Wikidata_query_service/User_Manual#Search_within_box. Not sure what is the best way to find something that is near that box. Maybe @Smalyshev (WMF): has a suggestion for an alternate approach.
      --- Jura 18:32, 14 June 2016 (UTC)[reply]
      • Well, right now WDQS has to know which corner is which coordinate. For latitude, I think you can guess which coordinate is the southern corner and which one is the northern. For longitude, it's not as simple because unlike latitude, longitude is continuous around the globe, and while you usually mean the smaller box theoretically you could also mean the bigger box going the other direction. Also, leaving it to the user will make automatic processing harder - not by a lot but even if you make a rule like "smaller box wins" or any other like this, processor will have to do something which is harder than not doing something :) So I'd prefer to have defined corner properties - preferably SW and NE corners - to make things easier. Alternatively, we could also implement box search with NW and SE corners, but I'm not sure it's worth the time. But having clarity which coord is which I think is important - it's kind of hard to make such decisions inside SPARQL query for example. --Smalyshev (WMF) (talk) 20:00, 14 June 2016 (UTC)[reply]
  •  Oppose I still think a bounding radius works much better with the existing coordinate location (P625) and is a better, non-biased fit to real-world structures that are usually not aligned to compass directions. --Srittau (talk) 23:37, 15 June 2016 (UTC)[reply]
    •  Comment Bounding radius sounds fine (esp. for indicating things like hunting range etc.)  But a bounding box, despite its axial orientation bias, has its uses too - say in breaking a space into quadrants for a search party.  A way to avoid the upper/lower right/left coordinate confusion would be to specify the bounding box central coordinate, and an angular latitude and longitude delta.  The extremity coordinates would be easily calculated from that, yielding a box.  This approach (a sibling of the bounding radius) assumes that the central coordinate is in the region being conveyed.  (Interestingly at a pole (+-90 deg. latitude), longitude is no longer relevant except that a 'width' vector can still be calculated along a line perpendicular to the longitude, in order to define the bounding box). Chindown (talk) 06:01, 22 August 2016 (UTC)[reply]
@Nikki, Jura1: Yes, the modifications makes the property ambiguous. As long as the "box" is rectangular, you can turn a (SW/NE)-pair into a (NW/SE)-pair by simple math. But if you do not know which corner the first property described, it definitely becomes very hard to use. -- Innocent bystander (talk) 20:35, 22 June 2016 (UTC)[reply]
@Innocent bystander: How is the math different between the two aspects? Why would we want to convert things before importing?
--- Jura 09:27, 23 June 2016 (UTC)[reply]
If you do not know if the Property:A describe the SW or the NW corner, how do you then know how the box looks like? A box covering Africa has its NW corner somewhere north of the the Canary Islands and the SW somewhere near Tristan da Cunha. But if you do not know if Property A describe the NW or the SW corner, the box could describe either true Africa or an area south from Tristan da Cunha, over the Antarctic, the Pacific, Europe and down to Gibraltar again. The box becomes ambiguous and not well-defined. -- Innocent bystander (talk) 09:51, 23 June 2016 (UTC)[reply]
You compare the two coordinates and, if needed, apply the "simple math".
--- Jura 09:54, 23 June 2016 (UTC)[reply]
It is simple transpose matrix (Q223683) to turn a SW/NE-pair into a NW/SE-pair. But if I do not know if the first is SW or NW, the box is ambiguous and you need more information. Earth and most other planets are spherical, not flat. -- Innocent bystander (talk) 11:24, 23 June 2016 (UTC)[reply]
In any case you do need more information: you need both properties.
--- Jura 11:32, 23 June 2016 (UTC)[reply]
That is not enough, you need a third property, two corners and a point telling which side of the two options is inside the box. -- Innocent bystander (talk) 11:36, 23 June 2016 (UTC)[reply]
Probably, I'm missing a point. I think the initial proposal had that problem if you concede that it could be the larger box, but I don't see how the current proposal has that. If 1 is north of 2, it's NW, if it's south of 2, it's SW.
--- Jura 11:41, 23 June 2016 (UTC)[reply]
For a map of the area around the South Pole is that not obvious. The NW corner could be -85;-85, the SE corner -70;+70 and the NW corner is then North of the SE corner. A map of the Old British Empire could include more than half of the Globe. -- Innocent bystander (talk) 15:10, 23 June 2016 (UTC)[reply]
Can we find this sample somewhere? To cover the pole, I think you'd have 90S. It would be interesting to see if WQS handles that. Maybe we are just expecting too much from bounding boxes.
--- Jura 18:06, 23 June 2016 (UTC)[reply]
You'd only have 90S as a bounding coordinate if 90S was on one edge of the map, which will not be true in a polar projection (nor other projections not centred on the equator). If you switch from having East and West coordinates to North and South then you have problems with the international date line. The only way around this is to specify which diagonally opposite corners are being used. Thryduulf (talk) 10:58, 9 July 2016 (UTC)[reply]
None of the samples by Susannaanas above supports bounding boxes that would somehow cross the poles. WQS doesn't do that either. For this type of map a bounding box may not be suitable. @Innocent bystander: can you provide us with a reference for your use case? (A source that uses a bounding box similar to define the scope of a map with parameters similar to the properties we discuss).
--- Jura 18:40, 10 July 2016 (UTC)[reply]
I am afraid I do not. The whole proposal is a little alien to me, I then simply need more to convince me! -- Innocent bystander (talk) 04:22, 11 July 2016 (UTC)[reply]
I tried to simulate your sample on WQS: [2]. I couldn't get it to return a meaningful result.
--- Jura 04:27, 11 July 2016 (UTC)[reply]
@Nikki, Jura1: Likewise I continue to support the original proposal for nw/se and I would also support sw/ne but I do not support the current ambiguous proposal. I have unmarked this as ready based on these last three comments. Thryduulf (talk) 08:31, 23 June 2016 (UTC)[reply]
 Comment I think that the change does not bring any advantages, and the original proposal already gained some consensus. It is a UI dilemma for the Wikidata page of how to input the data. Perhaps the data can be input in 4 values, and stored in two coordinate pairs if input as numbers. Or there can be additionally a visual interface to draw the bounding box. Most often data would be read or imported from another source, and formatting is required anyway.
  • Phab:T139824 is ready soon. It should support W/E corners. Did someone come up with samples of bounding boxes across poles that we should be supporting or can we go ahead with the current version?
    --- Jura 20:46, 31 July 2016 (UTC)[reply]

Bounding box with SPARQL: 

#Schools between San Jose, CA and Sacramento, CA
#defaultView:Map
SELECT * WHERE {

wd:Q986857 wdt:P625 ?SJloc .
wd:Q17152020 wdt:P625 ?SCloc .
SERVICE wikibase:box {
    ?place wdt:P625 ?location .
    bd:serviceParam wikibase:cornerWest ?SJloc .
    bd:serviceParam wikibase:cornerEast ?SCloc .
  }
?place wdt:P31/wdt:P279* wd:Q3914 .

}
Try it!


--- Jura 06:29, 2 August 2016 (UTC)[reply]

@Jura1, Susannaanas, Smalyshev (WMF), Nikki, Thryduulf, Innocent bystander:  Not done No consensus for the latest iteration. As this discussion shows again, changing a proposal majorly, especially when there is quite an involved discussion, is not a good idea. It's better to withdraw the proposal and make a new proposal. --Srittau (talk) 22:50, 19 August 2016 (UTC)[reply]

for use in defining mapping quadrangles

edit

I've been searching for a way to convey the quadrangles for geologic mapping. I guess this comes closest, but it seems there was never consensus. Too bad. I'd like to set the confines of a map or publication (scholarly article). US Geologic Survey has some really interesting tools putting geologic maps into google earth. I invite you to visit the Caetano tuff at USGS and click on the Google Earth KMZ link and open the file. It displays what to me is a lovely and interesting representation of geology and geography. Who to convey that or the boundaries of the quadrangle? I don't know, but I hope to learn. Trilotat (talk) 01:55, 3 December 2018 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/bounding_box&oldid=803974477"