query-be81ab85569f745ae326221f81dcf6c5
Bounding box east coordinates (2 of 2 pairs) → 70.09, 31.59(Q10542255)Finnish national grid coordinate system → 60.19526296266577, 24.999132404114395 (northeast / upperright)(Q17610148)Addresses and travel map of Helsinki from 1876 Example(Q22664)geographic coordinate system or rather (Q161779)spatial reference system , (Q4006)map DomainGeographic coordinatesData type(Q6865426) minimum bounding boxRepresentsone of two extreme points of a bounding box (NE or SE)Description Not done ]reply[09:58, 14 June 2016 (UTC) Jura--- was looking for this. Please insert your sample above Susannaanas I think Comment ]reply[10:45, 14 June 2016 (UTC)) talk (Susannaanas service. / Bounding Box uses coordinate values for each of the 4 edges and more notations can be found here in the DCMI model I did not yet add values, since I think it's worth discussing which values are best to use. Comment ]reply[10:56, 14 June 2016 (UTC) Jura--- 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. ]reply[11:04, 14 June 2016 (UTC)) talk (SusannaanasThanks! I made one possible proposal with upperleft/Northwestern – lowerright/Southeastern values. I hope this is usable for external use. Comments? / ]reply[07:24, 14 July 2016 (UTC) Jura--- phab:T139824 and phab:T139823:: Smalyshev (WMF)@ ]reply[05:14, 14 July 2016 (UTC)) talk (Smalyshev (WMF)For now, it'd be certainly easier if we knew which coordinate it refers to. However, if I manage to implement more generic interface, then two coordinate is enough, provided that it is known which one is which, but I think it'd be still easier if we mark them explicitly. Yes, that means 4 properties, if we want any combination, or 2 specific properties. The problem is SPARQL has no real conditionals, etc. - it's a declarative language - so if we don't know which corner means what, it may be hard to write proper query that captures all the cases. I'm open to ideas though on improvement of this. ]reply[16:29, 16 June 2016 (UTC) JuraEven in SPARQL, we should be able to determine if it's (SW and NE) or (SE and NW). So 2 properties should do: one for W, the other for E. -- ]reply[05:30, 16 June 2016 (UTC) Jura: Do you think we would need 4 properties are could that be done with 2? -- Smalyshev (WMF) ]reply[22:20, 15 June 2016 (UTC)) talk (Smalyshev (WMF)I see what you mean, it may be annoying to try and figure which thing should be in which corner. I'll see if I can make more automatic API there, depends on some technicalities. As for the property, however, I think it's better still to have exact definition of which corners it refers too. It will be easier to work with. ]reply[07:48, 15 June 2016 (UTC) Jura--- . I understand the argument about the advantage of defining the "smaller box" beforehand, but shouldn't we allow at least some flexibility as what corners to pick? [1] as NW and SE corners into the sample query to get the same result (Q17152020)Ashrama and (Q986857)Winters : Strange that I can't put Smalyshev (WMF) ]reply[23:05, 14 June 2016 (UTC)) talk (SusannaanasThanks, I hope I will get that beautifully in the proposal – SW and NE, that is! / ]reply[20:00, 14 June 2016 (UTC)) talk (Smalyshev (WMF)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. -- ]reply[18:32, 14 June 2016 (UTC) Jura--- : has a suggestion for an alternate approach. Smalyshev (WMF). Not sure what is the best way to find something that is near that box. Maybe @mw:Wikidata_query_service/User_Manual#Search_within_boxIt shouldn't matter. WQS can search within: ]reply[13:14, 14 June 2016 (UTC)) talk (Susannaanas Perhaps it is not necessary to fix whether the box is with upperleft-lowerright or lowerleft-upperright values? / Comment ]reply[06:01, 22 August 2016 (UTC)) talk (Chindown 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). Comment ]reply[23:37, 15 June 2016 (UTC)) talk (Srittau and is a better, non-biased fit to real-world structures that are usually not aligned to compass directions. --(P625)coordinate location I still think a bounding radius works much better with the existing Oppose ]reply[18:52, 22 June 2016 (UTC)) talk (Nikki: The proposal was changed (see above) and your support votes were based on the previous version of the proposal. Could you review the new version and check that you still support it? (The changes were significant enough to make me change my vote, maybe you also disagree with the changes). - Innocent bystander, Thryduulf@ ]reply[13:31, 19 June 2016 (UTC) Jura--- Per comments above, I updated the proposal to allow (SW and NE) or (SE and NW). Comment ]reply[08:31, 23 June 2016 (UTC)) talk (ThryduulfSee below. ]reply[.12:35, 16 June 2016 (UTC)) talk (Thryduulf per my comments in the various discussions that led to this proposal. Support ]reply[14:48, 16 June 2016 (UTC)) talk (Innocent bystander! -- Support The standard way on Wikipedia is NW/SE (probably based on how the coordinates in html are calculated). As long as it works, I ]reply[14:13, 16 June 2016 (UTC)) talk (ThryduulfI can't recall who, but someone indicated that bounding box data was available for a good many places/areas. A bounding box requires the coordinates only of two points not four for the N/S/E/W-most points (and any thing less than all four of those cannot be guaranteed to contain whole area). AIUI it's also a (the?) standard way to represent the area covered by maps, etc. ]reply[13:58, 16 June 2016 (UTC)) talk (Innocent bystander with the intension to not shipwreck this proposal at this early moment. I like this proposal, but since I do not see any significant difference to it relative the earlier N/S/E/W-proposal, I have to ask what the problems are and why this proposal do not have the same problems! -- }}O{{I have not added any "'coordinate of northernmost point' etc. are not lat/long values defining a bounding box, they're extremal points." (Same user) How isn't it the same thing? ) How couldn't that also be true about SW/NE-boundaries?The AnomeThe objection: "Extremal points are not always available" ( : I have, I was there when the discussions took place! But I do not understand how the objections against P1332/3/4/5 cannot be applied also to this pair of properties.Thryduulf@ ]reply[12:35, 16 June 2016 (UTC)) talk (ThryduulfPlease read the discussions linked above where the above properties have been discussed and rejected for this application. ]reply[10:41, 16 June 2016 (UTC)) talk (Innocent bystander. I think it looks like those properties can fulfil this purpose!? -- (P1335)coordinates of westernmost point , (P1334)coordinates of easternmost point , (P1333)coordinates of southernmost point , (P1332)coordinates of northernmost point We have properties like ]reply[18:43, 22 June 2016 (UTC)) talk (Nikki which corners are meant. That is completely unacceptable to me. - guessingIf you don't know which is north and which is south, you don't know enough about the bounding box you're adding and should not be adding the data anyway. This version does not explicitly define the bounding box, it requires ]reply[08:46, 22 June 2016 (UTC) Jura--- In its current form, it no longer requires you to know if its N or S. I guess then it's even better if you don't know it. ]reply[08:37, 22 June 2016 (UTC)) talk (Nikki. I think the changes are a bad idea and would make these properties much more annoying to use because you'll generally have to work out which is north and south before you can use the data. I'm not even convinced that it's always possible to determine whether a point is the north or south one (e.g. if it crosses a pole). I also don't see what the benefit to changing it is. If you know the NW/SE points, you can enter the NE/SW points. - Oppose The proposal has been changed, so changing my vote to ]reply[10:11, 16 June 2016 (UTC)) talk (Nikki: Pinging you as well because you contributed to that discussion. - Michiel1972, Ymblanter, Pigsonthewing, K7L (and the proposal directly below that one). @Wikidata:Property_proposal/Archive/52#map_zoom_levelThere was also discussion at ]reply[10:06, 16 June 2016 (UTC)) talk (Nikki: Pinging you because you all contributed to the discussion there) - Denny, Mahir256, ValterVB, Innocent bystander, Thryduulf, The Anome. (@Wikidata:Project_chat/Archive/2016/05#.22Approximate_radius.22_for_geographical_features per my comments on Support ]reply[06:19, 13 July 2016 (UTC) Jura--- ). This leaves us with the current proposal for W and E. Innocent bystander. The revised version with NW/SE corners initially just seem a bit to normative and possibly requiring unneeded transformation of coordinates, but it appears now that it leads some of its supporters to the mistaken assumption that boxes could spread beyond 90° (see discussion with Smalyshev: the initial proposal didn't quite work out for the reasons pointed out by Susannaanas ]reply[06:52, 11 July 2016 (UTC)) talk (SusannaanasOn another edge, I think more domains should be added in the proposal. / but I found them first of all semantically confusing, secondly they would need to be misused to represent the data (only one of the two values used for each property. Therefore, I hope, there is a clearly suitable property or properties to represent bounding boxes.(P1335)coordinates of westernmost point and (P1334)coordinates of easternmost point , (P1333)coordinates of southernmost point , (P1332)coordinates of northernmost point I would be willing to support using the properties 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. Comment ]reply[08:31, 23 June 2016 (UTC)) talk (Thryduulf: 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. Jura1, Nikki@ ]reply[04:27, 11 July 2016 (UTC) Jura--- . I couldn't get it to return a meaningful result. [2]I tried to simulate your sample on WQS: ]reply[04:22, 11 July 2016 (UTC)) talk (Innocent bystanderI am afraid I do not. The whole proposal is a little alien to me, I then simply need more to convince me! -- ]reply[18:40, 10 July 2016 (UTC) Jura--- : 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). Innocent bystander 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. @SusannaanasNone of the samples by ]reply[10:58, 9 July 2016 (UTC)) talk (ThryduulfYou'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. ]reply[18:06, 23 June 2016 (UTC) Jura--- 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. ]reply[15:10, 23 June 2016 (UTC)) talk (Innocent bystanderFor 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. -- ]reply[11:41, 23 June 2016 (UTC) Jura--- 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. ]reply[11:36, 23 June 2016 (UTC)) talk (Innocent bystanderThat is not enough, you need a third property, two corners and a point telling which side of the two options is inside the box. -- ]reply[11:32, 23 June 2016 (UTC) Jura--- In any case you do need more information: you need both properties. ]reply[11:24, 23 June 2016 (UTC)) talk (Innocent bystander 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. -- (Q223683)transpose matrix It is simple ]reply[09:54, 23 June 2016 (UTC) Jura--- You compare the two coordinates and, if needed, apply the "simple math". ]reply[09:51, 23 June 2016 (UTC)) talk (Innocent bystanderIf 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. -- ]reply[09:27, 23 June 2016 (UTC) Jura--- : How is the math different between the two aspects? Why would we want to convert things before importing? Innocent bystander@ ]reply[20:35, 22 June 2016 (UTC)) talk (Innocent bystander: 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. -- Jura1, Nikki@]reply[06:29, 2 August 2016 (UTC) Jura--- We haven't been able to find a referenced sample in 6 weeks. So let us conclude it doesn't exist. If there are no other remaining reasons, I think this is ready. ]reply[11:09, 1 August 2016 (UTC)) talk (Thryduulf). Innocent bystanderYou have not demonstrated that there will never be a box spread across poles, and that was only one of the objections brought up in the discussion (and not just with ]reply[05:32, 1 August 2016 (UTC) Jura--- Are there any reasons we haven't covered in the discussion with Innocent bystander? The problem with having these is that it seems to mislead us into believing that the box could spread across poles. An ambiguity that doesn't actually exist. ]reply[21:06, 31 July 2016 (UTC)) talk (ThryduulfFor the reasons expressed above I still oppose West and East, but support NW/SE or NE/SW. ]reply[20:46, 31 July 2016 (UTC) Jura--- 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? Phab:T139824Bounding box with SPARQL:
Use at
- https://query.wikidata.org/sparql
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX bd: <http://www.bigdata.com/rdf#>
#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 .
}