OpenAerialMap/Meeting Jan 29, 2015

From OpenStreetMap Wiki
Jump to: navigation, search

#hot: OpenAerialMap Meeting Jan 29 2015

Meeting started at 18:01:10 UTC. Meeting ended at 19:46:37 UTC.

Meeting Links

People present (lines said)

  • Cristiano (103)
  • wildintellect (95)
  • BlakeGirardot (30)
  • Fraank (4)


Jan 29 19:01:10 Cristiano: Good morning/evening everyone!
Jan 29 19:01:18 Fraank: Morning
Jan 29 19:01:26 wildintellect: hello
Jan 29 19:01:28 BlakeGirardot: Hi
Jan 29 19:01:58 Cristiano: Thank you for coming today. Blake offered to do the log work
Jan 29 19:02:37 Cristiano: We also have a draft agenda as a Google Doc
Jan 29 19:02:59 Cristiano: feel free to add anything you would like to discuss today
Jan 29 19:03:09 Cristiano: and add any comment
Jan 29 19:03:11 BlakeGirardot:
Jan 29 19:03:41 Cristiano: (thanks Blake!)
Jan 29 19:04:14 Cristiano: first I would like to quickly touch on the survey and see if there are any comments
Jan 29 19:05:08 Cristiano: The link is in the agenda. I added a couple of questions after Chris Holmes comments
Jan 29 19:07:04 wildintellect: the license question isn't really clear about open use vs restricted use licenses
Jan 29 19:07:27 Cristiano: Do you see anything that we may want to add or remove? Should we include more open questions?
Jan 29 19:08:07 wildintellect: I think you just need to clarify the options or the question
Jan 29 19:08:14 Cristiano: OK, how should we reframe it?
Jan 29 19:08:41 wildintellect: well really what we want to know is what restrictions are on the data
Jan 29 19:09:59 wildintellect: on the accuracy question does anyone really talk about it in pixels, or is meters the more common way to discuss
Jan 29 19:10:58 wildintellect: Are you familiar with the local laws, should be a yes/no radio button not free form fill in
Jan 29 19:11:07 Cristiano: OK. Something like "Are there any restrictions on the imagery you use"?
Jan 29 19:11:52 wildintellect: ya that might get better answers
Jan 29 19:11:53 Cristiano: Pixel is more relative to any scale/resolution, but I understand it could be too technical
Jan 29 19:12:06 wildintellect: so is this really "User" survey
Jan 29 19:12:19 wildintellect: seems more like a "Provider" survery
Jan 29 19:12:24 Cristiano: User/providers?
Jan 29 19:12:25 wildintellect: with some user questions
Jan 29 19:12:36 wildintellect: User = a person who comes to OAM looking for images
Jan 29 19:12:44 Cristiano: OAM users may be providers at the same time
Jan 29 19:12:45 wildintellect: Provider = and org that supplies images
Jan 29 19:13:04 wildintellect: sure but those are 2 different surveys
Jan 29 19:13:18 wildintellect: and a User survey should be much more about consuming data, and less technical
Jan 29 19:13:30 BlakeGirardot: re: license I think the confusing one to me is "ad hoc" does that mean "proprietary" or something similar, restricted, limited license, paid use only, something like that? Basically CC, public domain or other?
Jan 29 19:13:53 wildintellect: BlakeGirardot, yes thats the same concern I had with that question
Jan 29 19:14:32 Cristiano: Ad-hoc is when e.g. Digital Globe grants a specific license for a single disaster event
Jan 29 19:14:45 BlakeGirardot: I see.
Jan 29 19:14:56 Cristiano: " it can only be use by OSM to trace for this purpose etc..."
Jan 29 19:16:02 Cristiano: But if we ask what restrictions there are on imagery, then we should be able to capture those situations
Jan 29 19:16:12 wildintellect: Do you use a permissive license: yes/no if so which one fill in. If not: what restrictions : event limited, workflow limited, group limited
Jan 29 19:16:35 wildintellect: DG for OSM trace would be event and workflow limited
Jan 29 19:16:38 BlakeGirardot: And there is an accuracy and a resolution question, one in meters one in pixels
Jan 29 19:16:51 wildintellect: BlakeGirardot, I think Cristiano is editing as we talk
Jan 29 19:17:01 BlakeGirardot: Oh :)
Jan 29 19:17:09 Cristiano: not yet :)
Jan 29 19:17:09 wildintellect: I suggested meters instead of pixels
Jan 29 19:17:15 Fraank: agreed
Jan 29 19:17:40 BlakeGirardot: Oh yes, I was just getting to that one wildintellect, I saw your comment :)
Jan 29 19:18:01 Cristiano: meters for resolution and accuracy as well?
Jan 29 19:18:24 wildintellect: either that or explain what you mean by pixel accuracy
Jan 29 19:18:30 BlakeGirardot: The meters one I understand, the pixels one I don't, but I am not as experienced as everyone else
Jan 29 19:18:35 BlakeGirardot: here.
Jan 29 19:18:43 Cristiano: I guess if we take the combine answer is fine, but otherwise 1 meter accuracy could mean very different things depending on the resolution
Jan 29 19:18:57 Cristiano: *combined
Jan 29 19:19:11 wildintellect: sure, but most people will know resolution off-hand
Jan 29 19:19:43 wildintellect: accuracy, depends on the source - KAP/HobbyDrones won't know accuracy
Jan 29 19:19:53 Cristiano: OK, I'll reword those two questions
Jan 29 19:19:55 wildintellect: at least not without a lot of effort
Jan 29 19:20:10 wildintellect: but resolution you can figure by measuring in GIS
Jan 29 19:20:20 wildintellect: once referenced
Jan 29 19:20:27 wildintellect: or based on a known object size
Jan 29 19:22:25 Fraank: Assuming uploaders will be georeferencing any imagery they upload to OAM, wont most software be able to provide a resolution?
Jan 29 19:22:38 Cristiano: wildintellect: going back to user vs provider, at this point I was thinking to just focus on users, but try to include situations for when the user (e.g. Red Cross) is also a provider of imagery
Jan 29 19:23:25 wildintellect: Fraank, yes but we want an idea of what resolution people are looking to share
Jan 29 19:23:34 Fraank: gotcha
Jan 29 19:23:34 Cristiano: yes, they should. And if we require GeoTIFF or other already-GIS format it's embedded, right?
Jan 29 19:23:56 wildintellect: Cristiano, having some experience with surveys - you should split them
Jan 29 19:24:19 wildintellect: and for people who are also providers just put a link at the bottom, also a provider take the provider survey
Jan 29 19:24:44 Cristiano: OK. I feel I would have many more questions for the providers :)
Jan 29 19:24:49 Cristiano: but I like the link idea
Jan 29 19:25:26 BlakeGirardot: Oh, this read to me like it was aimed at providers
Jan 29 19:25:44 Cristiano: OK, I'll remove the provider-ish questions and put them in a second survey
Jan 29 19:25:53 wildintellect: thats most of the current survey
Jan 29 19:26:03 wildintellect: unless you reword to focus on end usage
Jan 29 19:26:26 BlakeGirardot: Re reading it knowing it is for users, I understand it a bit better
Jan 29 19:26:34 wildintellect: I would just rename this one to Providers
Jan 29 19:26:43 wildintellect: and make a fresh shorter/simpler User survey
Jan 29 19:27:00 wildintellect: some question would be similar but worded from a different perspective
Jan 29 19:27:44 Cristiano: OK, maybe I am thinking more of power-users rather than generic users
Jan 29 19:27:58 Cristiano: and from the perspective of a user=organization
Jan 29 19:28:56 Cristiano: let's see someone from the Red Cross office answers this survey, telling us how they currently do it, both sharing imagery and mapping
Jan 29 19:30:49 Cristiano: I'm thinking of OAM not just as a search and get-layer endpoint, more like a complete system to use for uploading, searching, offline sharing
Jan 29 19:31:05 BlakeGirardot: So when you say sharing their imagery, that means making it available to their end users
Jan 29 19:31:24 Cristiano: Yes
Jan 29 19:32:10 BlakeGirardot: Seems like we might need to refine that language a bit, sharing imagery = making available to OAM v. providing imagery to their end users for their own uses.
Jan 29 19:32:51 Cristiano: so, I guess there are power users (uploaders, installers of OAM) and end-users who are just accessing the imagery
Jan 29 19:33:23 BlakeGirardot: But I understand your "stand alone system" as well, red cross might download and locally install a OAM-S/M node to only be used in house.
Jan 29 19:34:55 Cristiano: right. OAM will be both an online service as well a portable standalone tile/catalog server
Jan 29 19:36:14 Cristiano: OK, then if you all agree we'll try to split this in two: power users / providers survey and end-user survey
Jan 29 19:36:15 wildintellect: so to me uploading implies, available for all users
Jan 29 19:36:42 wildintellect: obviously in an offline setup, it's just for local users
Jan 29 19:36:54 Cristiano: yes, if you upload to the main public OAM server
Jan 29 19:37:11 Cristiano: or if you upload to your local OAM for your local users
Jan 29 19:38:02 Cristiano: end user only deal with searching and accessing imagery in their Web/GIS/mobile clients
Jan 29 19:38:24 BlakeGirardot: Does this make any sense:
Jan 29 19:38:46 BlakeGirardot: The list of user types I made, feel free to add/change
Jan 29 19:39:47 BlakeGirardot: Because I see there is also a distinction of people/orgs that use our software v. people that provide or consume the imagery only and mixes of the two
Jan 29 19:41:03 BlakeGirardot: Or am I misunderstanding the different ways people could "use" OAM
Jan 29 19:41:18 wildintellect: really there are 2 uses
Jan 29 19:41:31 wildintellect: you can distribute data via OAM, and you can use data from OAM
Jan 29 19:41:44 wildintellect: so yes someone can be both
Jan 29 19:42:02 wildintellect: the fact that you could do it offline isn't really a new usage
Jan 29 19:42:04 Cristiano: Yes, and you can do both with an online OAM or with your local OAM
Jan 29 19:42:09 Cristiano: right
Jan 29 19:42:12 wildintellect: just has slightly different working parameters
Jan 29 19:42:47 BlakeGirardot: Ok. I understand what you both are saying.
Jan 29 19:42:57 Cristiano: OK. I'll come back with a revised version of the survey, or actually 2 surveys
Jan 29 19:43:10 Cristiano: let's move on unless there are other comments
Jan 29 19:44:19 wildintellect: sounds good
Jan 29 19:44:20 Cristiano: Or actually, still relevant to the survey, how do you think we should coordinate for dissemination?
Jan 29 19:44:33 wildintellect: snowball method
Jan 29 19:44:48 wildintellect: you send it to target orgs, and ask them to spread it
Jan 29 19:45:33 wildintellect: there are 2 types of orgs - Institutional and Community
Jan 29 19:45:35 Cristiano: sounds good, so we don't have to compile our distro list
Jan 29 19:45:54 wildintellect: it can be small, the NGOs you know, a few key agencies, and then OSM, OAM, OSGeo
Jan 29 19:45:55 Cristiano: I guess everyone can just spread the word
Jan 29 19:46:07 Cristiano: OK
Jan 29 19:46:14 wildintellect: those last 3 will spread it pretty wide
Jan 29 19:46:47 wildintellect: fyi, you need more than a free account to collect more than 100 reponses on a google survey - last time I checked (should recheck)
Jan 29 19:47:31 Cristiano: OK, I think Hotosm pays for it, but I will double check
Jan 29 19:48:31 Cristiano: Onto the metadata schema
Jan 29 19:49:23 Cristiano: just wanted to check quickly if you have any comments there. The idea is to keep it simple to start, but make it extensible to it would include options for describing raw (!) data in the future
Jan 29 19:50:53 Cristiano: this schema will be the basic set used for building the catalog and it's meant for georeferenced data only
Jan 29 19:52:19 Cristiano: it's a pretty standard and simple set and it came mostly from previous discussion, so unless there are any comment or additions we'll use it for reference when we issue the catalog tech challenge
Jan 29 19:52:24 wildintellect: BBOX and Coverage should be calculated
Jan 29 19:52:50 wildintellect: is this metadata per collection?
Jan 29 19:52:54 Cristiano: Yes, as well as projection and GSD
Jan 29 19:53:24 wildintellect: sure and you prompt user when it can't be detected
Jan 29 19:53:34 Cristiano: it will be handled directly by the uploading client or come together with the GeoTiff metdata for example
Jan 29 19:53:52 Cristiano: this metadata is per dataset
Jan 29 19:54:06 Cristiano: a collection could have multiple datasets
Jan 29 19:54:28 wildintellect: ok getting these terms defined would be good
Jan 29 19:54:45 wildintellect: I was thinking collection was a batch of images that belong together
Jan 29 19:54:54 wildintellect: same sensor, date, etc
Jan 29 19:54:57 Cristiano: let's say you either have a single GeoTIFF or multiple GeoTIFF tiles
Jan 29 19:55:10 wildintellect: yes one record for either
Jan 29 19:56:01 wildintellect: type and source should include WCS and ftp(well dir of files on a web server)
Jan 29 19:56:12 Cristiano: in case of multiple tile, it would be enough to provide the VRT together with the metadata file
Jan 29 19:57:13 wildintellect: overall the metadata list seems fine
Jan 29 19:57:29 wildintellect: I assume we are talking RGB images only?
Jan 29 19:57:47 wildintellect: ah I see it at the top
Jan 29 19:57:59 Cristiano: Yes, RGB only. Source is actually not well defined
Jan 29 19:58:19 Cristiano: I'm not sure if the initial OAM should rely/point to other services
Jan 29 19:59:55 Cristiano: So, I'd rather include sources more like FTP, direct upload
Jan 29 20:01:05 Cristiano: Unless OAM is able to fetch those TMS/WMS/WCS and cache them locally for fast serving
Jan 29 20:01:38 Cristiano: Or it would make more sense once we have a federation of reliable OAM servers
Jan 29 20:01:55 wildintellect: thats an important decision to make in the model
Jan 29 20:02:10 wildintellect: the original idea was distrubted data, central catalog
Jan 29 20:02:29 wildintellect: because bandwidth and disks would be prohibitive
Jan 29 20:03:01 wildintellect: same data could exist on multiple nodes
Jan 29 20:04:09 Cristiano: yes, a CDN with multiple nodes, but to start we need to build the first node
Jan 29 20:05:52 Cristiano: so, I guess it makes sense to keep it, but maybe change it to something like OAM:NODE:URI
Jan 29 20:06:55 wildintellect: well that source list should be a relate to a list of URIs
Jan 29 20:07:05 wildintellect: kinda like OSM tagging
Jan 29 20:07:15 wildintellect: you can pick a type, and give the uri
Jan 29 20:07:22 wildintellect: and do it as many times as you want
Jan 29 20:07:41 wildintellect: and if someone copies the data to another node, just add another entry
Jan 29 20:08:27 Cristiano: OK, that should work. I'm just not sure WCS or FTP would work in this case
Jan 29 20:08:55 Cristiano: Source would probably be just a list of TMS endpoints
Jan 29 20:10:52 Cristiano: OK, we'll work on that. Let's jump to the catalog design.
Jan 29 20:12:24 Cristiano: I kinda have an idea of the main features, but I was wondering what you guys think and how you envision it
Jan 29 20:12:57 Cristiano: Indexing, search, filtering and display?
Jan 29 20:14:12 wildintellect: that covers the basics
Jan 29 20:14:18 Cristiano: Trying to keep it lightweight to work both online, sourcing all OAM nodes and offline indexing local data only
Jan 29 20:14:47 wildintellect: though display is less critical, display of bounding boxes is useful
Jan 29 20:15:01 wildintellect: look at
Jan 29 20:15:36 wildintellect: not the best example of what to do, but the ability to see the overview outlines of data is useful
Jan 29 20:16:01 Cristiano: anyone familiar with CKAN or elasticsearch?
Jan 29 20:16:17 Cristiano: yes, we should have footprints/bboxes displayed
Jan 29 20:16:50 Cristiano: so, there needs to be some vector rendering map engine as well
Jan 29 20:17:27 wildintellect: my coworkers installed CKAN
Jan 29 20:17:36 wildintellect: but I haven't directly used it myself
Jan 29 20:17:56 wildintellect: I think Angelos from OSGeolive might be familiar since is ckan
Jan 29 20:18:13 wildintellect: well vector rendering is just js in a browser
Jan 29 20:18:30 wildintellect: and the bboxes can actually be WMS
Jan 29 20:18:34 wildintellect: with transparency
Jan 29 20:19:18 Cristiano: oh, that's right, we could just do the vector rendering in the browser directly
Jan 29 20:19:58 Cristiano: how would the data be stored so that js can access it? especially with larger catalogs?
Jan 29 20:20:52 Cristiano: catalog engine passing geojson out of the local db for each request?
Jan 29 20:21:54 wildintellect: pycsw can output bbox I think
Jan 29 20:22:00 wildintellect: probably as geojson
Jan 29 20:22:10 Cristiano: (I will contact Angelos - did he work directly on
Jan 29 20:22:18 wildintellect: no he's contract
Jan 29 20:22:25 Cristiano: OK
Jan 29 20:22:36 wildintellect: he works for a univ in greece somewhere
Jan 29 20:23:13 wildintellect: I'll send you his email address
Jan 29 20:23:25 BlakeGirardot: Did you see the libra browser for LandSat seedbox released last week?
Jan 29 20:23:44 Cristiano: OK, great.
Jan 29 20:23:58 BlakeGirardot: I am not suggesting it, but it is a pretty nice catalog browser
Jan 29 20:23:59 BlakeGirardot:
Jan 29 20:24:11 BlakeGirardot: not seedbox, developmentseed
Jan 29 20:25:48 Cristiano: very nice! Is it open source?
Jan 29 20:26:06 BlakeGirardot: I think it is, might be very landsat centric
Jan 29 20:26:27 BlakeGirardot:
Jan 29 20:27:31 wildintellect: its possible, talk to the mapbox people (mapbox came out of devseed)
Jan 29 20:28:25 Cristiano: Landsat is just any other imagery dataset, we should def look into it
Jan 29 20:29:48 wildintellect: sure you can make a general 30m resolution RGB of the world with it
Jan 29 20:30:19 wildintellect: though it's a little tricky for some uses in that regard
Jan 29 20:30:48 wildintellect: fyi we already have 1m airphoto coverage of the US available to use
Jan 29 20:30:54 wildintellect: from the previous OAM attempts
Jan 29 20:31:12 Cristiano: Yes, and newer NAIP as well
Jan 29 20:31:43 Cristiano: I was just saying to look into that libra browser code if it's availble
Jan 29 20:32:21 BlakeGirardot: I'll look into it. I think it is a nice lightweight and user friendly interface
Jan 29 20:32:25 Cristiano: we don't want to re-invest the wheel and optimize resources
Jan 29 20:34:57 Cristiano: With OAM though we would probably want to put those overviews on the map
Jan 29 20:35:17 Cristiano: no need for using part of the screen for it
Jan 29 20:35:58 Cristiano: and bounding boxes (or footprints) would probably be more complex polygons than Landsat scenes
Jan 29 20:36:13 wildintellect: ?
Jan 29 20:36:23 wildintellect: bbox is a rectangle with 4 points
Jan 29 20:36:51 Cristiano: Sorry, meant to say coverage
Jan 29 20:36:52 wildintellect: the downside of overlaying the data, is it becomes hard to read
Jan 29 20:37:32 Cristiano: what becomes hard to read?
Jan 29 20:37:47 wildintellect: the screen
Jan 29 20:38:08 wildintellect: well that and you'll need a WMS or tile server to provide the landsat or other image overlay
Jan 29 20:39:25 Cristiano: Well, we have the OAM TMS :-)
Jan 29 20:39:41 Cristiano: I'm thinking more like
Jan 29 20:39:56 Cristiano: where you see the imagery on the map directly as you browse
Jan 29 20:40:14 Cristiano: then you can change search params and see the data change on the map directly
Jan 29 20:40:37 Cristiano: but there would always be some base layer for reference
Jan 29 20:40:50 Cristiano: (Landsat or NAIP, etc)
Jan 29 20:42:16 Cristiano: OK. Let's think about it and come back with specific examples/designs/mockups next week
Jan 29 20:42:45 Cristiano: we would like to publish the first OAM Tech Challenge soon, by mid February
Jan 29 20:43:24 BlakeGirardot: Ok.
Jan 29 20:43:27 Cristiano: so, we need a semi-defined list of features by then :)
Jan 29 20:44:09 Cristiano: Thank you guys for participating today, lots of good ideas
Jan 29 20:44:23 wildintellect: Cristiano, it's a nice idea but I would put live map viewing lower on the list of priorities
Jan 29 20:44:36 wildintellect: being able to find and get the data is higher
Jan 29 20:44:57 Cristiano: OK, makes sense
Jan 29 20:45:34 Cristiano: we'll start with BBOXes first, then coverages (polygon), then full imagery
Jan 29 20:46:09 Cristiano: Blake: you captured the meeting log? Let us know when it's posted
Jan 29 20:46:18 BlakeGirardot: Ok, will do
Jan 29 20:46:25 Cristiano: Thank you and have a good rest of the day!
Jan 29 20:46:32 BlakeGirardot: Thank you Cristiano and wildintellect
Jan 29 20:46:37 BlakeGirardot: and Fraank