> > > > You said "It is a picture on a map - nothing more." My argument > was: > 1. That it is more. > 2. That the fact that it isn't more makes it *useful*, > which the other aspects of it do not. >
The point is - a picture is a picture. A picture is more valuable when it comes with the tabular data behind it. > > The arguments that I made apply equally to imagery and other > specialist GIS formats. KML is borderline (and that only > because of Google Earth.) CSV and shapefiles for GIS-related > data are not at all borderline. Hand a shapefile to the > Ushadhidi folks and tell them to get it into the map they're > using. (Their answer? "Ask the people who build the map.") > > > That is your argument not mine. You should be able to get the files out in the formats that are most useful to you and your background. Hence when we built out GeoCommons users have the option for getting the data out from any map as a KML network link, KML, .shp, .csv, GeoPDF, PNG, Atom, JSON, Spatialite. I'm just saying don't over look the non developer formats. Lots of people work with spreadsheets and never want to look at a map. Then give them the data as a spreadsheet. Not everything is a map and we should not assume it has to be so. > > > My argument is this: > > These formats require specialized knowledge that is > not held by the majority of the community who are > interested in the data. To the majority of people, > shapefiles are less interesting than maps that make > shapefiles available. > > The same can be applied to every data format (except > possibly KML; Google Earth changes the game there) > that you've mentioned. > > If I have a CSV file with lat/lon coordinates, 90% > of the time, it's more useful if I have them on a map. > > Isn't that that whole idea behind http://maker.geocommons.com/? > Maker fills the gap of #2 for certain problems, precisely because > layman can not do #2 on their own: they either need smart people, > or tools made by smart people. Maker is the latter, and pretty > good at that -- but it's specifically designed because people > who have a file can't do things with it without a smart tool! > > The whole #1,#2,#3 thing is your construct. Actually I think it is a quite nice construct, but is orthogonal to the point I was making in my posts. My only point is we should provide options and not over look non-developer formats. > > > But 90% of the applications that can use a shapefile are > expert tools. > In Afghanistan, Haiti, Pakistan, Katrina, London Bombings we ran into tons of people collecting data in spreadsheets. We are not going to change this so let's give them data as spreadsheets if that is what they are using. Then when they add to the data we can bring it back in. This is where we've worked on building tools to let them get their spreadsheets on maps easily. It is fair to say I have nothing against building useful tools, but that is not my point. It is providing data in formats the user community commonly work with. That said there are a good number of GIS folks out there so hook em up with shapefiles. They can do their thing and contribute back. Same with developers through Atom, JSON, Spatialite. I was trying to explicitly stay away from talking about what we do on GeoCommons because that was not the topic. I was trying to pass along the lessons we've learned seeing the vast majority of downloads during disasters being .csv and .kml. Lots of data being uploaded as .shp and .csv. Therefore if you are building out your own response app I'd recommend providing support because that is what we've seen people use tons of. > When you build a Web app it would be great if you could also get the data > used on top of it, out in a format that makes it re-usable. > > Most of the time, web apps for mapping are built either on > WMS services, tile services, or WFS services. All of these > are re-usable. Some of them are exportable/copyable. > None of these are portable without the Internet unless you bake a system to run off line. What you helped out with on the WorldBank terabyte thumb drives was a great prototype but this is not standard issue. We only made six of them. WMS services, tile services, or WFS services is just not as usable as a .csv, .kml or .shp for the person on the ground. We've been running disconnected on the ground in Afghanistan for a year and there are no humanitarian response folks or marines saying yo I have a WFS I want to give you on water purification project locations, nor are they downloading a WMS to go roll into the field for their next support operation. > > > That way I can take it into the field and do useful things with it; like > create derivative work that I can then contribute back and you can put on > your Web app. > > ... Okay, if you think that's a practical situation, then > you're right, we're coming from completely different worlds. > How do I not sound snarky on this. Yes they are completely different worlds - we do this on the ground every day. Let's start with Afghanistan - over 600 datasets contributed (none as WMS, WFS, or tile services) from over 30 NGO's. That is just the data pushed directly onto a portable GeoCommons appliance. Todd Huffman has another terabyte of data sitting on portable hard drives. How about Interaction which acts as the coordinating body for 180 humanitarian focused NGO's - doing the same thing there coordinating data from the field. All being pushed around as spreadsheets. It powers cool web apps like http://haitiaidmap.org/ - but when I need to push or pull data to the members in the field..... .csv Why because that is what they know how to use. > > > I shouldn't have to be a Web developer to do this or know how to use an > API. I'm not saying API's are useless. They are awesome for developers, > but not so awesome if you are not a developer and need some data to take > into the field or load into your app of choice. All the other things you > mentioned are important, but as a community "we" tend to be very tech and > Web centric. I'm simply trying to add the perspective of those on the > ground in disasters. > > > > It is a simple principle that comes from deploying into or supporting > many disasters, and seeing the frustration of those who can't access the > data they need. > > So you ignored the key question I asked in my previous email: > > > Very few of the people deployed to deal with a disaster have > > any way of dealing with GIS data, in my estimation. Are you > > saying you feel otherwise? > > It is getting better - that is something we are in the business of trying > to help. So, yes I like to think it is getting better through us and lots > of other folks trying to help out - OSGeo with GeoNode, RhizaLabs, > SpatialKey, CloudGIS, not all work in natural disasters but the mission is > the same. Again, though, this is not my point. We should give all stake > holders access to the data in formats they can utilize. Most of what I've > seen people working with in disasters are spreadsheets. > > It sounds like your answer is: "Yes, I feel that people on > the ground during disasters have the ability to work with > and edit GIS data." If that's the case, then I will simply > say that my experience and yours are completely different. > I'm glad that there are people who are exceeding my expectations; > I have experienced a lower common denominator. > You have a mix, so if you want to be effective serve a mix. > > During the Haiti crisis, I got emails from people saying "Okay, > I've loaded your map into Google Earth, and I can see that; > but now I want to see it with this KML, and I can't figure > out how to do that. Can you add this KML to haiticrisismap.org > instead, please?" > This was our whole motivation to build GeoCommons. During Katrina I had a spreadsheets coming out my ears from people wanting me to add them to a map, or even more sadly a .PPT of the map. Just as often they wanted the spreadsheet for the data they saw in my map because they wanted the list of addresses to respond to. Some times they wanted the shapefile to go run their own analysis off the data. Hence making all the data downloadable for any of those scenarios. > > Now, that's clearly not the common case: Google Earth should > 'just open' a KML file, and I don't know why this particular > Army official was having problems with it. But my experience has > consistently been that people who need information -- and are > on the ground in remote places -- often do not have the > expertise, experience, or tools, to even do so much as open > a KML file in Google Earth, much less do anything more complex, > like working with a shapefile in qgis. I'm sorry that I've > based my argument around my experience, but I don't really have > anything else to offer. > This is why giving them as many options as possible is key. Web services are nice but not a silver bullet. Personally, in a disaster, I'd take the downloadable data or even a GeoPDF over this http://www.gulfofmexicoresponsemap.com/ArcGIS/rest/services/MC252_Incident_Data/MapServer?f=jsapi because once I loose the Internet I loose my picture. Which was the point in the first place that seems to have gotten lost in all this. > > Regards, > -- > Christopher Schmidt > Nokia > > -- Sean P. Gorman PhD. FortiusOne Inc. 2200 Wilson Blvd. Suite 307 Arlington VA, 22201 Mobile: 202-321-3914 Office: 703-647-2151 @seangorman
_______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
