Extension talk:Gis/geo tag

From mediawiki.org
Latest comment: 17 years ago by 195.172.180.242 in topic Type
The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Tag format[edit]

The current format is:

  <geo>48 46 36 N 121 48 51 W</geo>

I would be much happier with something more like:

  <geo nd=48 nm=46 ns=36 wd=121 wm=48 ws=51 />

or even:

  <geo nd="48" nm="46" ns="36" wd="121" wm="48" ws="51" />

with extra attributes being contained like this:

  <geo nd="48" nm="46" ns="36" wd="121" wm="48" ws="51">type:mountain region:US scale:100000</geo>

If you were to make the quotes optional, this would not take up any more space. IMNSHO this format would make it much more difficult to make mistakes. --Phil | Talk 14:07, 30 Mar 2005 (UTC)

I would suggest the opposite. I'm fine with the coordinates being inside the tag, but additional properties that are clear name:value pairs should be added as attributes to the geo tag. For example:
  <geo type="mountain" region="US" scale="100000">48 46 36 N 121 48 51 W</geo>

No sense is making the parsing more difficult than it has to be... 75.33.66.211 03:46, 15 November 2006 (UTC)Reply

If there are to be any attributes then they should be marked up as well-formed xml, i.e. including quotes and case sensitivity. Anything else would be closing data access not expanding it. 195.172.180.242 12:08, 5 April 2007 (UTC)Reply

My thoughts[edit]

I strongly oppose the first suggestion above -- wiki markup isn't XML. It should be easy for a human to use, not cater to the computer. It strikes me that the most natural way to enter a base-60 number is to use colons as delimiters, just like you do for time:

 <geo>48:46:36 N 121:48:51 W</geo>

This is the format I'd like to see. This is easier and quicker for the eye to parse than either of the other formats. I don't believe either of the RFCs listed are appropriate precedents to follow. Both of their syntaxes follow the style of their particular formats and are not meant to be used outside of that scope. DNS resource records tend to have space-delimited fields so that is natural for that RFC. But it is hard for the eye to organize the 8 clumps of characters into the right larger clumps.

Also wanted to add that I like the XML-style format for the optional parameters in the second comment above. It is again more natural than inventing a new name:value syntax. So combining the two, I like:

 <geo type="mountain" region="US" scale="100000">48:46:36 N 121:48:51 W</geo>

If you want these attributes as part of the content, then I favor a nameless format:

 <geo>48:46:36 N 121:48:51 W US mountain 100,000</geo>

Any order. Allowing scales like 3E5 would be nice too. Perhaps a way of adding elevation data too... --GregU 06:19, 26 February 2007 (UTC)Reply

Type[edit]

Is the type list a little short? How do we go about suggesting additions/expansions to the list? 195.172.180.242 12:08, 5 April 2007 (UTC)Reply