Geo Elevation Data

I apologize if this has been been discussed before.  I
browsed through
the wiki and the list archives and couldn't find any
relevant threads
or pages.   So I joined the list to ask 

I'm developing an app that makes heavy use of geo-spatial
data, both
lines and points.  I'd like to incorporate the geo
microformat for
points, at minimum, however the coordinate data also
includes the
z-index (elevation) as well.

My first question is whether elevation has been proposed as
part of
the geo draft specification?  Adding the third dimension
would seem
natural and would add additional precision when adopted.

My second question is whether or not, for line data, it is
acceptable
to include multiple latitude and longitude classes, in
sequence, which
make up the line in sequence or if there is a better way to
do it?

Thanks,

- Jon

P.S. - Thanks for the great presentation at SXSW today,
Tantek and
others who presented. It brought home for me some great
possibilities
that I was missing!
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

From: "Jon Clausen" <ezods.jjcgmail.com>
>I apologize if this has been been discussed before.  I
browsed through
> the wiki and the list archives and couldn't find any
relevant threads
> or pages.   So I joined the list to ask 

Hi Jon, thakns for joining. It's always useful to receive
more input on 
these things.

> I'm developing an app that makes heavy use of
geo-spatial data, both
> lines and points.  I'd like to incorporate the geo
microformat for
> points, at minimum, however the coordinate data also
includes the
> z-index (elevation) as well.
>
> My first question is whether elevation has been
proposed as part of
> the geo draft specification?  Adding the third
dimension would seem
> natural and would add additional precision when
adopted.

Unfortunately the third dimension is being rejected at this
time. However, 
if the vCard spec is updated to include an altitude
component, then it will 
definately become a part of the hCard spec too.
http://micr
oformats.org/wiki/hcard-issues

If it does get decided to add an altitude component,  it'll
be explored 
first on the brainstoming section.
http://microformats.org/wiki/hcard-brainstormin
g#geo_improvements
But at this particular stage, extensions to hCard/vCard are
being currently 
rejected.

> My second question is whether or not, for line data, it
is acceptable
> to include multiple latitude and longitude classes, in
sequence, which
> make up the line in sequence or if there is a better
way to do it?

What kind of use do you envisage web tools being able to use
that line 
sequence information for?

This may be a case where something greater than the Geo
microformat (which 
is point specific) is required.

-- 
Paul Wilkins 

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

> Unfortunately the third dimension is being rejected at
this time. However, 
> if the vCard spec is updated to include an altitude
component, then it 
> will definately become a part of the hCard spec too.
> http://micr
oformats.org/wiki/hcard-issues


I think altitude might be useful to some people ...
eg a site about mountain climbing might want to mark up how
high the tops of 
the mountains are as well as where they are.
(and that information would probably have nothing to do with
anyone's 
contact details!)



_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 13.03.2007, at 04:57, Jon Clausen wrote:

> I apologize if this has been been discussed before.  I
browsed through
> the wiki and the list archives and couldn't find any
relevant threads
> or pages.   So I joined the list to ask 

Welcome to the list, Jon.


On 13.03.2007, at 05:24, Paul Wilkins wrote:

>> My first question is whether elevation has been
proposed as part of
>> the geo draft specification?  Adding the third
dimension would seem
>> natural and would add additional precision when
adopted.
>
> Unfortunately the third dimension is being rejected at
this time.  
> However, if the vCard spec is updated to include an
altitude  
> component, then it will definately become a part of the
hCard spec  
> too.
> http://micr
oformats.org/wiki/hcard-issues
>
> If it does get decided to add an altitude component, 
it'll be  
> explored first on the brainstoming section.
> http://microformats.org/wiki/hcard-brainstormin
g#geo_improvements
> But at this particular stage, extensions to hCard/vCard
are being  
> currently rejected.

To clarify, the geo microformat is a 1:1 representation of
the "geo"  
property in the
vCard standard. That's why extensions to geo are rejected as
well.

I also would like to see a (maybe new) microformat which
allowed for  
altitude at
least but hopefully also for different projections, date
systems and  
so on. There is
way more to geographical coordinates than what geo offers.
Jon, if  
you want to
start creating a new geo-like format, I'll gladly help. You
may want  
to look at the
process (http://microform
ats.org/wiki/process) first.

There are a few places you can start looking at, regarding
what  
others have done:
	- http://microformats.org/wiki/thoughts-on-extending-th
e-geo- 
microformat (abandoned)
	- http://
microformats.org/wiki/location-formats

Hope that helps.

Best regards,

	- Alex
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

 > What kind of use do you envisage web tools being able
to use that line
> sequence information for?
>
> This may be a case where something greater than the Geo
microformat (which
> is point specific) is required.

At the current time, that's difficult.   I'll try to give a
couple of
examples, though.  The app I'm developing has the ability to
upload
and import GPS data from 25 different formats common to the
major GPS
manufacturers.  From there it allows you to organize, share,
and
export that data (points and routes) as well as to export it
out in
any of those formats.

The common data which is standard across most of the formats
is Lat,
Lon, and Elevation.  Routes are stored as a collection of
waypoints
and are marked up differently, but  are the same basic data
- albeit
in sequence.

Along the way, I'm trying to plug-in the API to other tools
which make
use of spatial data such as Flickr.   Routes are a natural
progression
from points since they communicate time as well as space. 
If the
ability were there for a user to geo-tag their photos, and
map those
photos to routes or trails that they have taken, you might
have the
ability to share a "virtual tour" of their trip in
a mapped sequence
or exploration through current tools like Google Earth and
progress in
sequence.

Another example might be a of a Flickr user who sees a
series of
vacation photos organized into a route and wants to export
that route
and locations to the Spotstor (my app) API for export into
their GPS.
As noted before, Mountain climbing or hiking might be an
example of
this.   Another example might be persons who might want to
pass
directions to each other to meet up in a large corporate
campus - i.e.
- "here's my cube from where you are".  The 3rd
dimension would be
helpful there as well in multi-level buildings.

As I was in the "Spatial Reality" panel here at
SXSW a couple of days
ago, it kind of hit me that with the work Google is doing
around
mapping the 3rd dimension of cities and topography could
pose display
problems for data that doesn't contain a z-index.

Without the 3rd dimension, mapping those points using Google
earth or,
perhaps in the future, through Google maps, might cause the
waypoint
to be displayed inside an object instead of at the correct
elevation.

Hope that helps to clarify.   I can certainly submit a
proposal for
the route format - which would probably be best served by an
ordered
list containing separate geo elements:

<ol class="geo-route">
<li class="geo">
Latitude: <abbr class="latitude"
title="-83.00000">-83.0000</abbr>
Longitude: <abbr class="longitude"
title="43.00000">43.0000</abbr>
Elevation: <abbr class="elevation"
title="2012.00000">2012.0000</abbr>
<li>
etc....
</ol>

-Jon
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Mar 13, 2007, at 12:28 PM, Jon Clausen wrote:

> Without the 3rd dimension, mapping those points using
Google earth or,
> perhaps in the future, through Google maps, might cause
the waypoint
> to be displayed inside an object instead of at the
correct elevation.
>
> Hope that helps to clarify.   I can certainly submit a
proposal for
> the route format

Please follow the process:

http://microform
ats.org/wiki/process

You've gone through the "Why?" here, so the next
step is to document  
current behavior.  Who is currently publishing elevations,
and how  
are they doing it?  Are there any established formats for
this type  
of information?  After answering questions like these, we
should look  
at the possibility of using existing markup standards to
cover the  
information, including HTML structures and existing
microformats.   
Only when we've established that existing markup standards
fall short  
of solving the problem of standardizing real-world
publishing should  
we start thinking about new markup.  Because old markup
tends to be  
adopted more readily than new markup, and adoption is what
makes  
standards useful, new markup should always be a last
resort.

Peace,
Scott

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 3/13/07, Scott Reynen <scottrandomchaos.com> wrote:
> On Mar 13, 2007, at 12:28 PM, Jon Clausen wrote:
>
> > Without the 3rd dimension, mapping those points
using Google earth or,
> > perhaps in the future, through Google maps, might
cause the waypoint
> > to be displayed inside an object instead of at the
correct elevation.
> >
> > Hope that helps to clarify.   I can certainly
submit a proposal for
> > the route format
>
> Please follow the process:
>
> http://microform
ats.org/wiki/process

Will do.  Thanks for your help.

> You've gone through the "Why?" here, so the
next step is to document
> current behavior.  Who is currently publishing
elevations, and how
> are they doing it?  Are there any established formats
for this type
> of information?  After answering questions like these,
we should look
> at the possibility of using existing markup standards
to cover the
> information, including HTML structures and existing
microformats.
> Only when we've established that existing markup
standards fall short
> of solving the problem of standardizing real-world
publishing should
> we start thinking about new markup.  Because old markup
tends to be
> adopted more readily than new markup, and adoption is
what makes
> standards useful, new markup should always be a last
resort.

Absolutely.  I'll make sure that is all documented.
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message
<1b42308f0703131348ye81ed76l39f8b44fbb520739mail.gmail.com>,
Jon Clausen <ezods.jjcgmail.com> writes

>> >I can certainly submit a proposal for
>> > the route format
>>
>> Please follow the process:
>>
>> http://microform
ats.org/wiki/process
>
>Will do.  Thanks for your help.

Please be aware of:

        <http://microformats.org/wiki/geo-extension-strawman>

        (extends geo for representing coordinates on other
planets,
        moons etc.)

in order that routes on other bodies (e.g. the path driven
by Martian
landers) can be included.

Thank you - it would be unwise to "fork" Geo by
extending it in two
different directions, without consolidating those
extensions.

-- 
Andy Mabbett
                 <http://www
.pigsonthewing.org.uk/uFsig/>

                    Welcome to the world's longest week!
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <004001c76527$85ca0e10$bc08a8c0nzto22>, Paul Wilkins
<pmw57xtra.co.nz> writes

>> My first question is whether elevation has been
proposed as part of
>> the geo draft specification?  Adding the third
dimension would seem
>> natural and would add additional precision when
adopted.
>
>Unfortunately the third dimension is being rejected at
this time.

How very two dimensional!

> However, if the vCard spec is updated to include an
altitude
>component, then it will definately become a part of the
hCard spec too.
>http://micr
oformats.org/wiki/hcard-issues

I have yet to see any good reason why hCard (and Geo) cannot
have extra
fields, which are simply dropped when generating vCards
(likewise
hCalendar - see the "date of death" debate)

>> My second question is whether or not, for line
data, it is acceptable
>> to include multiple latitude and longitude classes,
in sequence, which
>> make up the line in sequence or if there is a
better way to do it?
>
>What kind of use do you envisage web tools being able to
use that line
>sequence information for?

Route mapping?

Boundary description?

>This may be a case where something greater than the Geo
microformat
>(which is point specific) is required.

There is no reason why this could not be an extension of
Geo.

Note also:

        <http://microformats.org/wiki/geo-extension-strawman>

-- 
Andy Mabbett
            *  Say "NO!" to compulsory ID Cards: 
<http://www.no2id.net/>
            *  Free Our Data:  <http://www.freeourd
ata.org.uk>
            *  Are you using Microformats, yet: <http://microformats.org/
> ?
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Am 15.03.2007 um 20:52 schrieb Andy Mabbett:

> In message <DCFF1356-345A-4CC8-A5DC-54FDE0759AC7deri.org>,  
> Alexander Graf <alexander.grafderi.org> writes
>
>>> <ol class="geo-route">
>>> <li class="geo">
>>> Latitude: <abbr class="latitude"
title="-83.00000">-83.0000</abbr>
>>> Longitude: <abbr class="longitude"
title="43.00000">43.0000</abbr>
>>> Elevation: <abbr class="elevation"
title="2012.00000">2012.0000</ 
>>> abbr>
>>> <li>
>>> etc....
>>> </ol>
>
>> as geo is just used for encapsulating Lat/Lon
values in hCards, I
>> don't think reusing is a good idea.
>
> I don't see how the above would break any existing (or
future spec- 
> abiding) "geo" or "hCard"
implementations; the elevation data and  
> geo-route class would simply be discarded.

Fair enough. Someone in this discssion said "geo"
was locked as it's  
a subset of hCard, which is locked too.
If geo is extendable that's even better!

  - Elevation is the main feature that is missing
  - Elevation could be positive and negative
  - Timestamps for geo data should be optional but possible
  - How about coordinate formats / map projection / dates?

- alex




_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss