Hi David,
David Colleen schrieb:
Hi Christian
There are three main reasons that you use a local coordinate system for most
3D application:
1. Z buffer performance in most 3D renderers.
2. Avoiding rounding error issues relating to navigation and camera control.
3. File bloat. Google Earths' KML/Collada files are typically 40% oversized,
in my tests, due to the use of lat/long descriptions for each vertex.
Ok, this makes sense and is resonable, but this are "just" performance
issues, which will dissapear with time and cpu/gpu power increase. I
think. :-) But for developing applications for the mobile devices of the
say next 5 to 10 years this should really be considered.
Typically, we work in UTM, WGS 84 with a local coordinate system for each
city.
I think, we really should avoid to use any of these 2D projected models
of space in 3D, as soon we don't depend on data in these systems any
more. But this will maybe need some time I guess... ;-)
best,
Christian
It's important to do 3D city work in UTM so that square buildings
remain square. Some systems use a per building local coordinate system. I
find this art path to be very awkward.
David Colleen
Planet 9
Hi all,
Maybe I don't understand what you talking about the necessity to use
local coordinate systems, so can one please clarify to me, why one can't
(or should not) model - as precisely as you just want - every single
(not moving) point on earth in a Geocentric Spatial Reference Frame [1]?
I see that actually the process of 3D modelling and grouping of objects
in systems with a own origin makes sense, but I can't see why a computer
can't do the same mathematical operations on numbers with just some more
digits?
Maybe I'm just blocked on that issue in the moment... :-/
Thanks and regards
Christian
[1]
http://www.euclideanspace.com/threed/solidmodel/geospatial/geocentric/index.
htm
Ron Lake schrieb:
You will need other local coordinate systems.
R
-----Original Message-----
From: Mike Liebhold [mailto:[email protected]]
Sent: August 31, 2009 5:13 PM
To: Chris Goad
Cc: Christian Willmes; Ron Lake; geojson; [email protected];
GeoRSS
Subject: Re: [Geowanking] [georss] [Geojson] simple 3D geocode for AR
H'mm. all great thoughts, mostly about camera focal planes grids,
pattern matching and spatial query formulations,
I'm still thinking more about the geocoded media, created for AR.
How will these sometimes sometimes huge, often, very small, data chunks
describe their precise 3D postion, for -- maximum discovery--
by the maximum number of crawlers, for yet to be invented fossgeo ar
clients , .com ar clients like layar and mobilzy, and 1000 more to
follow shortly, 3D map clients like google earth and bing [cringe], VR
worlds, mmorpgs, the whole web, etc.
Maybe it's just a URI including lat.lon.elev....crs... ?
now wondering if the location semantics in the URI could be as plain
language simple as a delicious, facebook or twitter URL.
?
Chris Goad wrote:
There is a substantive issue here to do with local coordinate
systems. When representing the features of a particular object it is
sometimes useful to employ coordinates local to that object, and
represent separately the position of the object in the world or
relative to its parent in a heirarchy. Reasons: The coordinates of
features relative to the object may be known more accurately than
global position of the object, and an AR device's relative position to
the object might also be known with greater precision than its global
position. The object may not have a fixed position (eg AR on board a
ship). The representation is more compact.
3d modeling formalisms support this (and full GML does too), but
GeoRSS, GeoJSON, and KML do not. This is probably an argument for
going to represententations built for 3d in the first place for AR
applications where local coordinates play a necessary role, but
concievably there is a niche for our lightweight geo standards
extended by addition of a transformation node.
-- Chris
----- Original Message ----- From: "Christian Willmes"
<[email protected]>
To: "Mike Liebhold" <[email protected]>
Cc: "Ron Lake" <[email protected]>; "geojson"
<[email protected]>; <[email protected]>; "GeoRSS"
<[email protected]>
Sent: Friday, August 28, 2009 6:00 PM
Subject: Re: [Geowanking] [georss] [Geojson] simple 3D geocode for AR
Hi,
whats the problem here? Its simple coordiante transformation stuff...
or do I miss something?!
The device gets the geocoordinates from the web, and computes those
using its own position and orientation to local camera
coordinates....
its that simple... I think. ;-)
regards,
Christian
Mike Liebhold schrieb:
Ron Lake wrote:
The most logical coordinate
system for locating such items is a rectilinear coordinate system
(x-y-z
frame) centered (origin) at the focal point of the camera.
What's the use case?
In most cases, we probably can assume that the geo-annotations exist
independent of the viewpoint; e.g. a viewer should be able to see
the note attached to a restaurant from any perspective as they pass
on a sidewalk, or drive by.
In that case, we need absolute coordinates, not relative to the
camera perspective.
imho
Mike
Cheers
Ron
-----Original Message-----
From: Mike Liebhold [mailto:[email protected]] Sent: August 28, 2009
2:05 PM
To: Ron Lake
Cc: Joshua Lieberman; [email protected]; geojson; GeoRSS
Subject: Re: [georss] [Geojson] simple 3D geocode for AR
Ron Lake wrote:
The use of geographic coordinates for [location of things in the
field
of view relative to the camera] likely does not. [ make sense]
Ron,
This is really counter intuitive, Can you explain what you mean?
- Mike
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Joshua
Lieberman
Sent: August 28, 2009 11:03 AM
To: [email protected]
Cc: geojson; GeoRSS
Subject: Re: [georss] [Geojson] simple 3D geocode for AR
In both GeoRSS GML and GeoJSON, some explicit CRS needs to be
specified to use 3-coordinate locations. The simplest one for
GeoRSS seems to be epsg:4979 ( urn:ogc:def:crs:EPSG:4979 ). It
would need a slight modification to support the GeoJSON long-lat
encoding. Otherwise use GeoRSS Simple and the elev property.
e.g.
<georss:elev>346</georss:elev>
<georss:point>42.3234 -173.234134</georss:point>
Well-known text description of 4979
(http://spatialreference.org/ref/epsg/4979/ )
GEOGCS["WGS 84", DATUM["World Geodetic System 1984", SPHEROID["WGS
84",
6378137.0,298.257223563, AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0.0,
AUTHORITY["EPSG","8901"]], UNIT["degree",0.017453292519943295],
AXIS["Geodetic latitude",NORTH], AXIS["Geodetic longitude",EAST],
AXIS["Ellipsoidal height",UP], AUTHORITY["EPSG","4979"]]
Josh
On Aug 28, 2009, at 1:05 PM, Ron Lake wrote:
Sorry my example should have been
<Point id = "P1" CRS = "http://www.blah.bla/standardCRS.xml";>
<coordinates>100 200 150</coordinates>
</Point>
But the argument is the same. Similar encodings can be made in
JSON
etc.
R
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Andrew
Turner
Sent: August 28, 2009 9:57 AM
To: [email protected]; GeoRSS; geojson
Subject: Re: [georss] [Geojson] simple 3D geocode for AR
Simplest?
Just include a 3rd coordinate in GeoRSS-Simple point or GeoJSON
point.
No, this is not explicitly valid. But you see where that
discussion
gets us. Long windy roads of elusive semantic talk (arguably
necessary
in the lon term, but not simple or useable *now*, which is when
people
are building these tools).
If we lose interest without achieving a near term concensus,
developers will just do arbitrary, different solutions. Give them
a
simple answer now, even if it makes your
strict-validation-only-skin
crawl just a little bit. :)
So I say just do it, and we'll catch up with documenting it as
uses
emerge.
Also, KML already supports 3D points.
Andrew
(via mobile)
On Aug 27, 2009, at 4:35 PM, Mike Liebhold <[email protected]> wrote:
A friend wrote me with a request for clarification on a topic
we've
discussed many times here, but every time we've approached a
consensus the answer seems elusive.
Many devleopers are starting to create applications for iPhones
and
Android phones to view location specific data through the
viewfinder using the -imprecise- capabilities of the built in
gps
and compass and applications platforms like Layar.
The question:
What is the -simplest- way to geocode a geoannotation in 3D
using
geoRSS/Atom, geojson, KML ....?
(Is there a practical reason why WGS '84 shouldn't be implicit,
and
a CRS lookup NOT be required?)
_______________________________________________
Geojson mailing list
[email protected]
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
_______________________________________________
georss mailing list
[email protected]
http://lists.eogeo.org/mailman/listinfo/georss
_______________________________________________
georss mailing list
[email protected]
http://lists.eogeo.org/mailman/listinfo/georss
_______________________________________________
georss mailing list
[email protected]
http://lists.eogeo.org/mailman/listinfo/georss
_______________________________________________
georss mailing list
[email protected]
http://lists.eogeo.org/mailman/listinfo/georss
_______________________________________________
Geowanking mailing list
[email protected]
http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
_______________________________________________
Geowanking mailing list
[email protected]
http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
_______________________________________________
Geowanking mailing list
[email protected]
http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
_______________________________________________
Geowanking mailing list
[email protected]
http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
