[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] loading browser-based map sites in udig as base/background layer?
|
On Jan 4, 2008, at 6:21 PM, Jody Garnett wrote:
Eric Jarvies wrote:
A license agreement.
i just need a way to overlay my shapefile(s) atop sat images, so i
can make visual references for the purpose of denoting whether or
not there is construction/structures atop a given section of land,
if certain elements/landmarks are indeed there, and tasks along
these lines. purely for visual reference for the sake of aiding me
in performing various overlay vector-based tasks.
Cool; you want to try the Nasa World Wind servers? It may be exactly
what you needed...
Follow the walkthrough 1 instructions to add my community plugin to
your eclipse and they will show up in the catalog.
i will add it and give it a try, thank you.
in mexico, if you take and view street-level and sat images in hybred
mode, you will see that street-level roads are several meters off most
cases. when someone like myself adds his own shapefiles to the mix,
ported to kml or mashed-up via openlayers, these same errors occur,
but not uniform with those of googles own errors. so a mashed-up map
containing a google sat image of the road, a google street level path
of the road(making a hybred view), and then add my own ported
shapefile/postgresql/etc path of the road to the mix ... it's a
disaster. google's road is several meters of to the left, and mine
are several meters off to the right. for small maps, with little
data, i cna simply make the adjustment. but for maps covering a
larger geographic area, these single-movement global adjustments do
not work, because google seems to not have a uniform means by which
they stitch all of their sat imagery together(or so it seams). so this
requires may adjustments though-out the entire map from top to bottom
and left to right and corner to corner. most of my shapefiles have
tens of thousands of polygons to them(property and construction maps),
and so it consumes a lot of time editing these. nothing worse then
seeing a 500 meter lot sitting in the middle of a google sat image
street. the maps/correction to google maps in the states seems far
better then it is here in mexico, and for obvious reason(more people
use geo-map-related products and services up there).
making these types of changes in an openlayers mash-up is not
practical at this point in openlayers' development, imho. however, it
would work ideally in udig, especially having controls off screen/map,
and having the ability to lock-into-position the background web-
map(google, etc.) so that one can move foreground editable layers to
make corrections. once an area/region has been corrected, unlock the
web-map background so one can pan/zoom(so all the layers pan and zoom
together) to a new area/region, and make changes to that part of the
user's maps ... with the convenience of google maps in the background,
or yahoo, or mapquest, or microsoft, or openstreetmap, or any other
map site of the same nature.
as far as messing with accuracy ... who cares, so long as the
duplicated/purposed modified maps look good when they are mashed-up
with google, etc., then thats what matters. the only people that will
notice these adjustments wil lbe those using google maps/earth for gps
tracking, in which case their path will clearly be where the correct
road locations are, and not where the google and above-mentioned
edited/purposed maps roads are. but even then, tracking typically run
at 30-60 second intervals, so gps paths are all over the place,
cutting corners through buildings and parking lots, etc. speaking of
which, does a gps module exist for udig?
I think you can get a yahoo id of some sort and armed with that we
could grab images. I know that the open street map project managed
to make arrangements along those lines.
programmatically, what would it take(time and otherwise) to
implement openlayers into udig, wherein the controls(zoom, pan,
etc.) are moved off screen/map and onto/into their own buttons/
controls.
I am not sure at this time; depends how well you can invoke
javascript on a embeded mozilla browser. Some research is needed ...
but honestly it sounds like you want a web application at this stage?
i merely want a way to edit layers atop the actual product they will
eventually be residing upon, being able to do so with yahoo, mapquest,
google, and microsoft, openstreetmaps, and even other map sites or
clients with map sites in place, that may need something i have to
offer, and prior to delivering it, and without having to mash-up
anything, i could simply use udig to do the proofing. if i need to
deliver 20 city blocks of property polygons atop a google map for
example, i want to make sure the lots are within the streets, and
everything looks good, so that when the end user eventually sees and
uses it, they are satisfied, hence the client is satisfied. of
course, as part of the map-making process in terms of actual content,
having sat images from various sources with which to use as reference,
is nice/beneficial. in one afternoon, i can vector-draw 100 roads
that is see on a sat image, and the next day i can go to the location
and collect names, et.c. from those who live there, and pretty much
have a map that would otherwise take a week or two to create.
obviously the age of those images may mean some roads are not there,
but those ones are discovered when on site, and that amount of field
collection is minimal. if i am in the office, and a co-worker is in
the field with his gps cellular phone, i can set a udig layer that
receives the coordinates from him at various fixed positions we've
agreed on, or can receive 30 seconds updates marking where he is. if
i need him to go to lot# 345, i right click the lot(or ctlr click,
whatever) and initiate a message to him, i type in some instructions,
and a few seconds later he receives the coordinates/message. right
now, i can see where all my people are in the field(via geoserver/
openlayers and some custom java). they have their gps enabled
cellular phones, with shapefles loaded in a simple viewer/editor,
allowing them to obtain all the info they need without a data
connection(because they have the maps loaded onto their handhelds,
only the coordinates and messaging need be sent back and forth, hence
low edge/data consumption).
for those of us who wish to share their maps/data, the above-mentioned
allows us to do so easily. can place openstreetmaps as a background,
and then overlay our own maps, and easily remove from our maps what
openstreetmaps already has documented/mapped, then easily take that
edited map/data and upload it to openstreetmaps, for example. heck,
udig could do the same for openaerialmaps, and any another site like
these. again, being able to take ready work, work in progress, and
final delivery vehicles(ggogle maps), and make them play nicely in one
area.
what would really be cool, is if udig had the capability of service up
a current view, be it one layer or 20 layers. but just being able to
serve up that view, and then via geoserver-meets-chat, take and serve
up that view to another udig user, who receives the view as a layer
within his udig. this would make collaborating easier, and a lot more
visual and too the point. it would avoid having to transfer heavy/
large files, and would allow it to happen very quickly. just think
chicken of the vnc, or remote desktop sharing, but instead of it being
an entire desktop, its the rendered view pane of a udig user, and the
recipient receives the layer, showing up in his udig layers pane, with
coords/projection. etc. info. when the sender changes his view/scale/
appearance/whatever, the recipient gets updated, or gets another
served layer. the recipient can then take that served layer, mash
it up with his own stuff, and serve something back to the original
sender. ok, kinda went off topic here.
In addition, adding an easy 'add map site' feature, affording the
user the ability to enter the respective info for the respective
site(openstreetmaps, yahoo, google, etc.). and finally, having it
so that it is the bottom/back/background layer in the layer stack,
allowing other layers to be loaded atop, like shapefiles, etc.,
wherein the top layers conform to the zoom(scale) and projection of
the background map-site, thus allowing the user to easily pan and
zoom in and out, whilst editing his/her top-side vector layers, and
also being able to lock-down the site-map background, whilst being
able to move the top-most layers around freely(for alignment, like
scale, move, skew, etc. of any top vector layer, as to properly
align with said web-map view ... we all know that our maps never
line up with their maps ... like in google, roads can be several
meters off).
udig is a browser(amongst other things), correct?
Not really - uDig is an application. You can embed a browser widget
into it - see the "Web" view as an example - what is being shown is
a simple web page, clicks on this web page are listened for and if
you click on a capabilities document udig will open it up.
ok. understood.
google, yahoo, etc. have no restrictions as to the type of browser
that can display those sites and their respective content/data//
maps. everything would be served up the same way for all intents
and purposes.
I am afraid what they all want is the ability to track the user;
hense the javascript api.
fine, let them track, it will appear as any other normal map user. no
problems here, because what i speak of causes absolutely NO problems
nor does it pose any threat to anyone, especially google, etc., or
none with any merit. it would not be downloading thousands of tiles,
or using the images for re-purposing or bundling in another app, or
anything along those lines. it would be for the sake of making sure
the maps we create, conform atop those maps being served by google,
etc. it's legitimate, and there is nothing backdoor or sneaky about
this. their mark/name remains on all the tiles, and all the tiles are
served just as they would be in any other browser, on any other
computer, on any other day, by any other person. we want our maps to
look better atop their maps/product, and until they can either fix
their maps, or provide developers with a tool to do as i've mentioned
above, then what other solution do they suggest? the api would be
used as it is licensed, so nothing would be different, and certainly
nothing would be infringing.
i have been dealing with data acquisition execs at google for the past
year or so, regarding my latin american maps, and more so, my poi dBs,
and their desire to get them/use them. in several emails, i've made
mention of the fact that i use google sat images as a means of making
my own vector maps, a sort of digital tracing as described above. i
never received any negative words, much less even a polite warning, or
a prod of any sort. and why should i? i am not infringing, and what
i speak of above does not infringe.
by implementing openlayers into udig, and moving the controls off-
screen and onto their own buttons/menus, this would essentially
empower the udig user, and again, would not serve to violate the
rights of any mark or copy holder.
I see what you are saying; sounds a bit shaky to me. On the
technical side of things the embeded browser is a full widget; not
sure if we can overlay a transparent window overtop of it.
it should be thought of as a means by which one can confirm his or
her maps for easy export to kml, etc, for use on these 3rd party
map sites. being able to load up one of the maps sites, and then
load your content files atop, you can take a visual look around,
make the adjustments/changes that are needed, and then export your
content to the respective site/program format for use in a mashed-
up environment.
I was going to handle a similar problem to this using context
documents (drive open layers and udig from the same context document
- subst the google maps layer with something on sound legal footing,
and then exporting the context document to the web, possibly
publishing the shapefile to a geoserver or mapserver if needed).
forgive me, i will start filing bug tickets over in your trac front
end starting this next week, and will start helping out with spell
correction and document checking, etc., so i can read-up and come to
speed on the project's back-end, and inner workings. until then, i'll
pretend to keep up with what your saying(meaning). but seriously, if
openalyers can mash-up map layers inside of a browser, why then could
not udig accomplish this within it's own environment, locally?
problem here is resolution when zoomed in close. it's bad :(
The joy of free data; what application did you need to this result
in? Yahoo is pretty lax about the restrictions. Also you can totally
set up an image mosic with a pretty amazing level of detail if you
have some disk space to burn.
again, i revert back to google, etc., and their high-res sat images.
they are being publicly served. there are api's, and there are terms
of use, based on the licensing agreements they have with their
providers. what i speak of above falls well within normal use, as we
are viewing a google map webpage just as anyone else would be. we are
not re-purposing the tiles or anything else along those lines.
i would like to see this implemented in udig, but alas, i am a
developer, not a programmer. so, if anyone else would be
interested in performing the required work to make this feature-set
a reality, i would indeed do my part in gui/button/etc. design,
copy, and financial contribution. l see no heavy lifting here, and
everything seems straight forward to one who is a competent
programmer, familiar with udig's trunk/code-base. does anyone else
see the value in this feature-set?
I will bounce the idea off Paul, see if the idea is sound enough to
send you a quote. Sorry to be hesitant on this one, I know the
various data providers would love to sell you high quality
background imagery; as such they are very careful about what they
allow google and yahoo to "give away" for free.
nothing i mentioned or suggested in any way even comes close to
infringing on google's, or their providers licenses/rights. no maps
are being re-purposed or re-distributed, or copied(facsimile, digital
byte for byte, etc.). in fact, nothing more or less is happening
other then they are not being viewed in a popular web-only browser.
this direction merely holds them on a users screen for as long as the
user wishes(nothing out of the normal), and allows the user to use
them as a more precise tool for reference.
adios,
eric
Cheers,
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
