Talk:Mashup: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
imported>Howard C. Berkowitz
(→‎GIS APIs: new section)
Line 26: Line 26:


[[User:Howard C. Berkowitz|Howard C. Berkowitz]] 12:36, 6 August 2008 (CDT)
[[User:Howard C. Berkowitz|Howard C. Berkowitz]] 12:36, 6 August 2008 (CDT)
== GIS APIs ==
Some of my work is with maritime navigation, and, while I haven't specifically worked with the Google maps API, I would urge very great caution in mashing up (is that the verb?) geospatial information if there is the slightest chance anyone might try to use it for navigation. There are issues both of coordinate systems and of map data format (see http://www.beachwerks.com/Chartplotter/CP-charts.html for some discussion)
The EULA for DEC computers, for example, was invalid for air traffic control or nuclear power control without a supplemental agreement. I get very nervous when trying to combine geospatial information, which can be very very good, or if it is bad, it is horrid. For example, at the TOPOFF 2 national-level emergency management test for a simulated "dirty bomb" in Seattle, the Incident Command System software was doing things like taking the EPA's atmospheric plume propagation model, and variously superimposing it onto population census data and on topographic information. The population data helped give the priorities for evacuation (e.g., office building for a day incident vs. apartment house for a night incident); the topographic information, with human interaction, let specialists judge where a piece of elevated terrain might be a low-radiation spot in the general plume.
With medical information, there are the usual disclaimers of not doing something unless you consult a medical professional. I am concerned that a generalized mashup may try to combine information that would appear to be compatible, but have hidden warnings. For example, if I'm doing a chartplotter application, I need to know whether I'm getting a regular GPS signal, or the higher-resolution DGPS/WAAS. For the latter, it starts being important where, on the boat, the GPS receiver is located. Most seamen will dock by eye, but there have been some situations where people over-relied on <1 meter WAAS, and crunched their boat because the GPS antenna was not in the centerline of their boat. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 15:16, 13 August 2008 (CDT)

Revision as of 14:16, 13 August 2008

As a networking sort of person, except for specialized applications, I look forward to an introduction or at least a definition. IIRC, a fry-up is an English breakfast, so maybe a mashup involves electronic transmission of breakfast potatoes? Howard C. Berkowitz 22:54, 3 August 2008 (CDT)

Mashup in other fields

I wonder if this is similar to imagery intelligence#geospatial intelligence, which is the merger of imagery with precise geographic coordinates, or multispectral imaging, where, for example, visible color photographs are merged with images taken outside the visible range, but the various wavelengths combined into a "false color" image meaningful to an expert. Howard C. Berkowitz 04:06, 6 August 2008 (CDT)

John Snow, etc.

John Snow, and, independently, Florence Nightingale, are generally credited, at least in epidemiology, with introducing the idea of "business graphics" to present tables of numbers — pie charts, histograms, and the like.

So, their methods have been in use, mostly manually, for about 150 years. I'm not sure that citing their example, other than it is a general user interface example, helps me understand what is new about a mashup.

Is it something like a business intelligence dashboard (e.g., http://www.enterprise-dashboard.com/)?

So far, I see a number of analogies to things that contribute to mashups, but I still don't have any idea what are the essential qualities that make a particular user interface (I think mashup seems to be a user interface) a mashup, rather than another kind of presentation.

Howard C. Berkowitz 12:03, 6 August 2008 (CDT)

API vs. remote procedure call

This may be pedantic, but I don't think of HTTP as being either an API or a remote procedure call. The semantics are different.

Now, HTTP is clearly a client/server protocol, and, in one sense of the word, does invoke a remote service/server. That may, at the server, involve some internal procedure invocations, but invocations, in the sense of UNIX/LINUX interprocess communications or the Remote Procedure Call protocol, RFC1057 http://www.ietf.org/rfc/rfc1057.txt) RPC: Remote Procedure Call Protocol specification: Version 2. SunMicrosystems. June 1988.

To me, an HTTP API on one's own computer causes an HTTP protocol message to sent, which doesn't necessarily invoke a procedure. I think of a service as made up of a set of procedures, some of which will invoke others on the sane nachine and some (very common in large server farms) may be load-distributed among transaction/database servers. For the databases, as an example, NFS over XDR over RPC has the semantics of a remote procedure call -- but it's the RPC that imposes those semantics, not an application protocol (interface) such as NFS or HTTP.

Howard C. Berkowitz 12:36, 6 August 2008 (CDT)

GIS APIs

Some of my work is with maritime navigation, and, while I haven't specifically worked with the Google maps API, I would urge very great caution in mashing up (is that the verb?) geospatial information if there is the slightest chance anyone might try to use it for navigation. There are issues both of coordinate systems and of map data format (see http://www.beachwerks.com/Chartplotter/CP-charts.html for some discussion)

The EULA for DEC computers, for example, was invalid for air traffic control or nuclear power control without a supplemental agreement. I get very nervous when trying to combine geospatial information, which can be very very good, or if it is bad, it is horrid. For example, at the TOPOFF 2 national-level emergency management test for a simulated "dirty bomb" in Seattle, the Incident Command System software was doing things like taking the EPA's atmospheric plume propagation model, and variously superimposing it onto population census data and on topographic information. The population data helped give the priorities for evacuation (e.g., office building for a day incident vs. apartment house for a night incident); the topographic information, with human interaction, let specialists judge where a piece of elevated terrain might be a low-radiation spot in the general plume.

With medical information, there are the usual disclaimers of not doing something unless you consult a medical professional. I am concerned that a generalized mashup may try to combine information that would appear to be compatible, but have hidden warnings. For example, if I'm doing a chartplotter application, I need to know whether I'm getting a regular GPS signal, or the higher-resolution DGPS/WAAS. For the latter, it starts being important where, on the boat, the GPS receiver is located. Most seamen will dock by eye, but there have been some situations where people over-relied on <1 meter WAAS, and crunched their boat because the GPS antenna was not in the centerline of their boat. Howard C. Berkowitz 15:16, 13 August 2008 (CDT)