Difference between revisions of "Category talk:Split cities"
imported>Danatar (→PROPOSAL: Split the split city graticule pages.) |
imported>Aperfectring (→Comments) |
||
Line 28: | Line 28: | ||
* '''support''' --[[User:Ekorren|Ekorren]] 12:11, 1 July 2009 (UTC) | * '''support''' --[[User:Ekorren|Ekorren]] 12:11, 1 July 2009 (UTC) | ||
* '''support''' - [[User:Danatar|Danatar]] 13:01, 1 July 2009 (UTC) | * '''support''' - [[User:Danatar|Danatar]] 13:01, 1 July 2009 (UTC) | ||
+ | * Somewhere between '''support''' and '''DNO''' --[[User:Aperfectring|aperfectring]] 13:13, 1 July 2009 (UTC) | ||
=== Comments === | === Comments === | ||
Line 36: | Line 37: | ||
Same here. I live near a graticule border and my city has a part in the graticule east of it, but the graticules have different names and it works fine that way. When I plan to visit a hashpoint e.g. in the eastern graticule, I note it on that graticule's page. If somebody is interested in visiting a certain graticule, he/she can watch that graticule's page and will find the note that way. People from the graticule border on the western side of my graticule will probably not be interested in hashpoints to the east and won't watch that page. That way they won't be bothered by any "graticule page has been changed" emails; If there was only one common page for both graticules, every second expedition would be too far away (= more than 1°) for them to go. - [[User:Danatar|Danatar]] 13:01, 1 July 2009 (UTC) | Same here. I live near a graticule border and my city has a part in the graticule east of it, but the graticules have different names and it works fine that way. When I plan to visit a hashpoint e.g. in the eastern graticule, I note it on that graticule's page. If somebody is interested in visiting a certain graticule, he/she can watch that graticule's page and will find the note that way. People from the graticule border on the western side of my graticule will probably not be interested in hashpoints to the east and won't watch that page. That way they won't be bothered by any "graticule page has been changed" emails; If there was only one common page for both graticules, every second expedition would be too far away (= more than 1°) for them to go. - [[User:Danatar|Danatar]] 13:01, 1 July 2009 (UTC) | ||
+ | |||
+ | First off, I agree with you two. However, there are some cities which are particularly badly affected by being split, e.g. [[Denver, Colorado]]. Personally, I could see them splitting it into 2 and I think 4 is overkill in that case, but with the southern 2 graticules of the Denver split, the city is quite evenly cut into two parts. I can definitely see why people in Denver would want to have a single page for planning purposes, but the northern two graticules don't seem to me like they belong in that joint city. I wouldn't go so far as to say that having a split-city page is against the spirit of geohashing in and of itself, but how they are currently used does seem a little against the spirit, in that they tend to be used solely to get the closest point, which will usually end up in the city itself. Having only split-city pages definitely does alienate the far reaches of the graticules involved when a point is always chosen because of its proximity to the city center. My opinion is that split-city geohashers should have normal graticule pages, with the list of residents, and list of expeditions in that graticule. They can combine planning for a set of graticules on another page (I don't think this really solves the problem), or on one of the graticule pages (my preference), and provide a link to where planning goes on. [[Portland, Oregon]] and [[Vancouver, British Columbia]] are good examples of how to do the latter. I think a split-city approach to planning only would be fine if it wasn't primarily used to go to the easiest/nearest point. --[[User:Aperfectring|aperfectring]] 13:13, 1 July 2009 (UTC) |
Revision as of 13:13, 1 July 2009
Check out Adelaide, Australia, it has a pretty solid layout that I blatantly stole for Twin Cities, Minnesota. Redsai 21:51, 28 May 2008 (UTC)
Contents
Split Cities Templates
Hey folks, just thought I'd announce two templates joannac and I created:
They are just like Template:Graticule, but are specially designed for cities that occupy two graticules.
Having just seen that four-graticule straddlers exist, I may consider another template... but not today. -- Matty K 13:08, 21 October 2008 (UTC)
- Actually, I couldn't let it just sit there. So, Template:GraticuleQ. The documentation includes a working example for Twin Cities, Minnesota. --Matty K 13:32, 21 October 2008 (UTC)
PROPOSAL: Split the split city graticule pages.
I would like to propose the following:
- To transform the aggregated split city graticule pages into separate graticule pages.
- To create separate pages for communities or cities which wish to do a joint planning or have a joint activity report.
Cross-graticule communities may then decide to include the content of the joint planning/activity report page on all graticule pages in question (you can do this with regular pages just as you can do with templates), or alternatively to just set up a link to their community and a note which points interested people in the right direction. Content from active split city pages can be moved to the joint page.
I propose this mainly for the following reasons:
- Split city pages are not automatically maintained in the case of (formally or factually) inactive graticules.
- The split city approach stems from a time when there were few active graticules which usually were hosting a single community. I think it is time to separate these concepts.
Votes
support, oppose, needs work, and a short comment please.
- support (ftr) -- relet 11:55, 1 July 2009 (UTC)
- support --Ekorren 12:11, 1 July 2009 (UTC)
- support - Danatar 13:01, 1 July 2009 (UTC)
- Somewhere between support and DNO --aperfectring 13:13, 1 July 2009 (UTC)
Comments
your ideas, rants and questions here
I never saw much sense in combining several graticule pages into one only because there was a city which has parts in both. There usually are lots of towns which get "incorporated" into those combined pages although they are not part of the split city. E.g. there is totally no sense in combining Lübeck and Rotenburg/Wümme into one page, is there? Geohashing is about coordinates and graticules, and not about cities, anyway. So, it might be convenient for a city community to have one combined page, but it's totally against the systematics and, IMHO, also slightly against the spirit of geohashing, and it's totally dumb for the parts of the graticules which are not even close to the city in question. --Ekorren 12:11, 1 July 2009 (UTC)
Same here. I live near a graticule border and my city has a part in the graticule east of it, but the graticules have different names and it works fine that way. When I plan to visit a hashpoint e.g. in the eastern graticule, I note it on that graticule's page. If somebody is interested in visiting a certain graticule, he/she can watch that graticule's page and will find the note that way. People from the graticule border on the western side of my graticule will probably not be interested in hashpoints to the east and won't watch that page. That way they won't be bothered by any "graticule page has been changed" emails; If there was only one common page for both graticules, every second expedition would be too far away (= more than 1°) for them to go. - Danatar 13:01, 1 July 2009 (UTC)
First off, I agree with you two. However, there are some cities which are particularly badly affected by being split, e.g. Denver, Colorado. Personally, I could see them splitting it into 2 and I think 4 is overkill in that case, but with the southern 2 graticules of the Denver split, the city is quite evenly cut into two parts. I can definitely see why people in Denver would want to have a single page for planning purposes, but the northern two graticules don't seem to me like they belong in that joint city. I wouldn't go so far as to say that having a split-city page is against the spirit of geohashing in and of itself, but how they are currently used does seem a little against the spirit, in that they tend to be used solely to get the closest point, which will usually end up in the city itself. Having only split-city pages definitely does alienate the far reaches of the graticules involved when a point is always chosen because of its proximity to the city center. My opinion is that split-city geohashers should have normal graticule pages, with the list of residents, and list of expeditions in that graticule. They can combine planning for a set of graticules on another page (I don't think this really solves the problem), or on one of the graticule pages (my preference), and provide a link to where planning goes on. Portland, Oregon and Vancouver, British Columbia are good examples of how to do the latter. I think a split-city approach to planning only would be fine if it wasn't primarily used to go to the easiest/nearest point. --aperfectring 13:13, 1 July 2009 (UTC)