Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

links to osm.org with box=yes no longer show bounding box rectangle #5055

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 19 comments
Closed

Comments

@openstreetmap-trac
Copy link

Reporter: aseerel4c26
[Submitted to the original trac issue database at 10.38am, Tuesday, 3rd December 2013]

does not show the bbox like before (a yellow/orange rectangle, IIRC). Example: http://www.openstreetmap.org/?box=yes&bbox=-4.269454,55.851998,-4.240465,55.864957 used in the description of https://wiki.openstreetmap.org/wiki/File:20130223_DSC1072_Looking_at_Buildings.jpg

Here it still works: http://owl.apis.dev.openstreetmap.org/?box=yes&bbox=-4.269454,55.851998,-4.240465,55.86495715/47.3372/8.0414#map=15/55.8585/-4.2550

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 4.10pm, Tuesday, 3rd December 2013]

The box=yes parameter was an internal implementation detail of the old data browser and was never intended to be used by anybody else. We have no plans to support it going forward.

@openstreetmap-trac
Copy link
Author

Author: aseerel4c26
[Added to the original trac issue at 3.17pm, Friday, 6th December 2013]

It was documented at https://wiki.openstreetmap.org/wiki/Bbox (see the link). ;-) You see also ( ticket #5060 ) that it ''is'' used.

You'' have no plans to "support it going forward". ''Others could help to fix this loss of functionality, right? So, please could we keep this bug open?

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 3.22pm, Friday, 6th December 2013]

I'm not responsible for people choose to put in the wiki, nor do I have any way to stop people putting things there which use unsupported features of the interface.

When I say we have no plans to support it my point is that we no longer have any need for the code that was used to do this, and we don't want to add that code back just to provide it as an end-user feature, any more than we support the overlaying of any other random shapes on the map by end users.

People wanting that sort of things should use a service that is designed to provide customisable maps to end users.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 3.24pm, Friday, 6th December 2013]

Incidentally I see no mention at all of box= on that wiki page, only of bbox= which we have now restored.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 3.24pm, Friday, 6th December 2013]

Oh I see, in the link, well that's hardly promoting it to anybody - it's probably an accident more than anything else.

@openstreetmap-trac
Copy link
Author

Author: aseerel4c26
[Added to the original trac issue at 3.44pm, Friday, 6th December 2013]

So, where (if not in the wiki) is the documentation of the officially supported interface features? The wiki is promoted as "documentation" even on our www.osm.org homepage.

You are constantly confusing "we" and "I", don't you? "don't want to add that code back" and "any need for the code that was used to do this" You may not like a box, fine. But others do.

Why is "bbox" restored (so it apparently is not only for endusers) but "box=yes" is not (so, apparently not for endusers)? I do not see the difference here.

Following your enduser argument you could shut down the whole map display on osm.org.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 3.50pm, Friday, 6th December 2013]

We in this context means the people who will have to maintain the code going forward - even if somebody else writes the code in the first place there is always a long term cost to be born in mind when accepting it so it's not a simple case of integrating every feature somebody chooses to write.

We restored bbox because we considered it sufficiently useful and also in large part because it has been documented over a long period of time as a way to display a specific area. It also had minimal cost in terms of it's interaction with the rest of the code and the likely future maintenance burden.

The cost of restoring box=yes is more significant because it means bring back infrastructure components which have been removed, and then maintaining them purely to be able to continue drawing those boxes which no part of the site would otherwise need.

@openstreetmap-trac
Copy link
Author

Author: aseerel4c26
[Added to the original trac issue at 3.58pm, Friday, 6th December 2013]

@ your previous comment:

So you say that the clear documentation as "parameter" (";box:Is the rectangle of the bbox to be displayed :default : yes.") [https://wiki.openstreetmap.org/w/index.php?title=Template:Bbox&diff=971823&oldid=289474 before your change] should have been an accident?

By the way: you have just changed the default(!) behaviour of this template do not forget to check all the wikipages using this template (they may refer to a "box" in the associated text ). Luckily just a handfull (I guess more pages may use direct URLs).

What about just admitting that you were wrong in the determination what "we" want and use?

@openstreetmap-trac
Copy link
Author

Author: aseerel4c26
[Added to the original trac issue at 4.00pm, Friday, 6th December 2013]

"no part of the site would otherwise need" ... I do see a box at the map display of http://www.openstreetmap.org/changeset/654321 , you don't?

@openstreetmap-trac
Copy link
Author

Author: Robert Whittaker
[Added to the original trac issue at 11.30am, Monday, 9th December 2013]

I previously made use of this functionality, e.g. in links to point to a specific section of a National Cycle Network Route, such as http://www.openstreetmap.org/?minlon=0.8969&minlat=52.3616&maxlon=1.1020&maxlat=52.3865&layers=C&box=yes and I'm disappointed that it was removed without any consultation.

I would regard such functionality as a simple extension of the ability to link to an OSM.org map with a particular point highlighted by a marker. This is part of the "share" functionality, achieved by adding mlat=* and mlon=* in the URL. No-one would try claiming that that is something that end-users should go to a third-party site for. Indeed, previous UI changes, even introduced a UI for adding the marker, so end-users didn't have to hack the URL to get it.

Linking to a basic rectangular area is also quite fundamental, and is something I believe OSM should support. The fact that there is a "share" button in the right-hand bar shows how important it is considered to allow the sharing of links to OSM -- presumably because we value the exposure. Restoring this functionality will give people another reason to link to OSM. (Not to mention restoring the previous behaviour that people expect from existing links and bookmarks with box=yes.)

As mentioned above, the argument about maintaining code is rather suspect, given that the ability to draw such boxes on the map must still present in the code (for the changeset and history views. Restoring the functionality should therefore just be a matter of interpreting the box=yes part of URL, and calling the relevant existing function in the code. Or am I missing something here?

@openstreetmap-trac
Copy link
Author

Author: Robert Whittaker
[Added to the original trac issue at 12.07pm, Monday, 9th December 2013]

The previous functionality was (and currently still is) documented in the wiki under https://wiki.openstreetmap.org/wiki/Browsing#Sharing_a_link_to_the_maps . So even if some people didn't intend it to be used, it was documented in the official wiki for 4.5 years as something you could do.

Moreover, a comment in the editing history of that page, suggests that the original implementation of minlat=&maxlat=&minlon=&maxlon= may have drawn the visible box by default, and only later did the behaviour change to require box=yes to get the box to be shown.

It's then interesting to see who added the original bbox URLs to that wiki page (albeit without the box=yes parameter): https://wiki.openstreetmap.org/w/index.php?title=Browsing&diff=46709&oldid=46707 .

@openstreetmap-trac
Copy link
Author

Author: openstreetmap[at]firefishy.com
[Added to the original trac issue at 12.42pm, Monday, 9th December 2013]

This bug is closed. Loudly complaining here will not change things.

If you wish to maintain (semi-documented) historical backward compatibility please create a pull request on github.

@openstreetmap-trac
Copy link
Author

Author: aseerel4c26
[Added to the original trac issue at 1.14pm, Monday, 9th December 2013]

@ "openstreetmap@": You mention again "semi-documented". So, where (if not in the wiki) is the documentation of the officially supported interface features? I did ask this before, but got no reply, to by knowledge.

@openstreetmap-trac
Copy link
Author

Author: aseerel4c26
[Added to the original trac issue at 1.36pm, Monday, 9th December 2013]

Firefishy removed the whole section about "bbox URLs" https://wiki.openstreetmap.org/w/index.php?title=Browsing&diff=972474&oldid=963311&rcid=&curid=1322 from the wiki page. So bbox links are now not supported anymore? I thought just the box=yes is not anymore?! At least currently the bbox links still work. He has reverted this partly - only box=yes is removed now.

Sadly, for example (there are more instances like that) my work at [https://wiki.openstreetmap.org/wiki/File:20130223_DSC1072_Looking_at_Buildings.jpg File:20130223_DSC1072_Looking_at_Buildings.jpg] where I invested time to provide a good link to the osm.org map (with exactly the shown map and with the visual box) is half destroyed now.

@openstreetmap-trac
Copy link
Author

Author: Robert Whittaker
[Added to the original trac issue at 2.29pm, Tuesday, 10th December 2013]

Re comment 12. Fair enough: openstreetmap/openstreetmap-website#650

I still regard the lack of this functionality as a defect, but if you're willing to accept pull requests, this issue should at least be allowed to stand as a feature request.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 2.31pm, Tuesday, 10th December 2013]

Request rejected.

@openstreetmap-trac
Copy link
Author

Author: cmuelle8
[Added to the original trac issue at 2.44am, Monday, 10th March 2014]

May we have any insight as to why this was rejected? The feature is helpful for a lot of cases where a marker won't do. Take a look at www.oldmapsonline.org - these all have bounding boxes. If people want to create a link in an attempt to show the same crop of these old maps area on osm.org, it's hard to do. You do not want to setup leaflet for every such purpose.

Google Maps easily shows bbox by submitting a short KML snippet.

I'd suggest doing it the other way around: Supporting this feature more thoroughly - e.g. by shading everything that is outside the crop area. This would benefit changeset bbox view as well..

@openstreetmap-trac
Copy link
Author

Author: cmuelle8
[Added to the original trac issue at 2.47am, Monday, 10th March 2014]

reopening so the request is seen. please close this bug for a reason that is explained, not just because it bugs.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 7.04am, Monday, 10th March 2014]

There are entire essays already written here explaining it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant