This is why.

Let me anticipate the inevitable “why don’t you just use Google Maps” question: to the best of my understanding, tracing your airport vectors off of Google Maps imagery is an unlicensed use of their service and would result in a derived product owned by Google.  That’s pretty much a deal breaker.

OSM’s use of background imagery to trace (in Potlatch) comes from specific license agreements between OSM and the image provider – in other words, the image providers are “donating” to OSM by giving them a specific license to trace without ownership issues.

Anyway, I am open to other ideas.  (Except for “no, you didn’t read the license right, Google really doesn’t mind if you use their imagery for free to create your own data set”.  I am not open to that! 🙂

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

28 comments on “WED 1.2 Doesn’t Use TerraServer

  1. What about the ability to use GeoTIFF imagery? There is a ton of publicly available orthophotos, whether through national sources or state, and it does not have the licensing restrictions of Google and others. I am more familiar with the US imagery, but I believe there have been other public projects in other countries.

    1. That already exists! 🙂 When you add a GeoTiff as a reference image, the location info is automatically used to position it.

  2. Well, one (kind of roundabout) way might be tracing airports over Bing or Yahoo imagery in JOSM, exporting the result to OSM, and then importing the airport from OSM for touching up in WED.

  3. Maybe allow import from OSM?

    Do the trace in OSM and then import into WED? OSM is allowed to use Google’s maps, and you’re allowed to use OSM data (even more so if you did the trace yourself).

    This has the added bonus of improving OSM at the same time…

  4. Tracing? How about verification or even just eyeballing? Proof of the first is almost impossible to secure. From your perspective it is understandably different, of course, because of its inclusion in an app.

    I just wanted to ask because I’m a total noob. Does this have the potential to irretrievably break my project done in 1.1r1? I have lost it once already but in an early stage of development. I’m not expecting a guarantee, just a qualitative estimate of degree of confidence.

    1. Huh? What breaks your project in 1.1r1 exactly? All 1.1 WED sessions should “just work”, except that you can’t turn on the TerraServer layer, which frankly was just going to give you “500 error” anyway.

      1. Unidentifiable and long gone. The message was “Unable to open .XML file: not well-formed (invalid token).” No clue how to get that one back but restarting was easy using the data of the unworkable one.

  5. Hi Ben
    How about a standard WMS layer, just like in other GIS based softwares (JOSM, QGis etc)? User can manually configure service with standard WMS reguest string. I know – this is not for every user, but there are many local WMS services, which provides sometimes very accurate resource (various kinds of maps, orthos atc..).

  6. I’ve been using Bing/maps imagery for WED, I checked the images of KMYR on Bing and Google Maps and they are different, so I’m not sure which is most recent.

  7. There’s already a bunch of area polygons, runways, and buildings in OSM, so providing access to one of their tilesets would at least provide that kind of data. You can’t trace decorations or fine detail from there, but it’d be something.

    1. Right – an OSM tile-set is an option too – I need to read the tileset use guidelines carefully, as they do have rules for “high usage” clients to keep their servers from getting murdered.

      1. When done properly, I doubt it’d be high-traffic. Ideally, once a user starts working on an airport and have determined the area, WED would just selectively download the few tiles they need for the area. That can all be automated, and requires only very few tiles at the start of a project. At most, further work would require downloading a few more tiles further down the road.

        All in all, that would cause way less traffic than the average slippy map use of a single regular OSM user.

  8. Seconding the WMS option – I’ve used a number of open MapServer APIs for rich ArcGIS data sets for various regional authorities and these have included high-res orthos and poly data avail in diff formats including GeoJSON and KMZ. Thinking about it, an option in WED to resolve a layer of vector data (point or polygon) in WED from a user-specified URL supplying GeoJSON or KMZ data would be useful. Even cooler, a scripting API in WED to enable scenery authors to do stuff like batch assignment of OBJs against point data locations.

    1. Indeed, it would be more flexible and put the licensing onus on to the user. The only issue which I can see being a problem are you kinda have to rely on the good merit system for submitting airports to Robin since I believe GPL’ed and not knowing the origin of airport tracing would be a problem … I know the Flightgear folks who also use Robin’s data might probably raise this question.

    2. We could someday have various data import formats, but the ability to import, process and use GIS data is perhaps an orthogonal feature to reference imagery.

  9. While there is a little bit of available imagery, it seem to be bits & pieces from all over – like // provide imagery gratis for Canada & Nth America.

    I wonder if some kind of plugin capability would allow users who wanted to subscribe to say Google data or some other data source to do so? Not sure how this would work but I suspect a tools like WED could benefit greatly from a plugin capability – to provide custom tools (a bit like Sketchup does using python) and interfaces to data sources for terra data.

    1. Re: plugins…WED is available in source. Would the advantage of a plugin system be run-time linking, a change of language (to a higher level x-platform one) or a cleaner interface into WED?

      1. Probably a matter of lowering the bar (higher-level x-platform) and being able to share tools. A person who can write python or some other scripting is not necessarily a c programmer. It leaves a strong core to WED and a lighter addon for things people may or not see as useful.

        However, I’m well aware this is not a trivial thing to implement and probably depends a lot on the way tools and interfaces are currently implemented and whether they can be (reasonably easily) exposed through a scripting interface. The other thing would be to find out if there is a sufficient number of x-plane scenery developers who would take advantage of such a capability to warrant spending any time on it. If there’s only a couple of hundred WED users, contributed code would seem better. If there’s a 1000 users, a scripting interface might be useful.

        Maybe I should make a tool for WED (something simple like a measuring tool) using the current source so I don’t sound so much like I’m making this up as I go along 😛

  10. Have you guys ever considered to be bought out by Google?
    1.If X-Plane shared geo data with Google Earth X-Plane users could enjoy more realistic scenery with orthophoto textures and improved building models
    2. you all guys in Laminar become millionaires (even though Austin already is, he’d become even richer)
    3. Microsoft would get their ass kicked by Google on another front

    I can see only advantages 🙂

    1. Yes, but this was considered to be “plan B”. plan A was that Larry and Sergei just give us $500,000,000 each with no strings attached, as well as full access to all of Google’s data and IP, and in return, Austin takes them for a ride in his airplane. 🙂

      1. just so every one is clear, selling to google is creepy, not giving the guys $500M each

  11. How about taking Austin’s plane on a worldwide aerophotogrammetry tour and then creating your own earth database so you never again have to depend on an external vendor’s licensing terms?

    Sorry, couldn’t resist… 😉

Comments are closed.