Saturday, November 19, 2011

Legal and Policy Framework for a 'Location-enabled' Economy

I have been giving some thought as to the fundamental elements of a legal and policy framework necessary for the development of a 'location-enabled' economy. For purposes of this post, I am defining a 'location-enabled' economy as one that allows the full potential of geospatial technologies to be realized while addressing legitimate concerns, such as privacy.  In my opinion, nations that develop such a framework will be better suited for economic growth, high quality government services, increased public safety and homeland security and protecting natural resources. In addition, these nations will be the leaders in addressing transnational issues such as climate change. Thus far, I have come up with the following (in no particular order):

1. Laws, regulations and policies with respect to the collection, use and transfer of geospatial data are clear and transpartent;

2. Any regulations that restrict the collection of geospatial data - of any type - are narrowly-tailored to address specific and articulable concerns, rather than broadly defined so as to address any potential risk;

3. Due to its unique qualities, geolocation information is protected for privacy purposes differently than information such as social security numbers, financial information or medical records;

4. Government agencies make government data (or Public Sector Information (PSI)) broadly available at minimal or no cost;

5. Intellectual Property Rights (IPR) in geospatial data are clear, widely understood and when appropriate, adequately protected;

6. Geospatial technology is treated the same as other types of technology;

7. There are no restrictions on the import and/or export of geospatial data;

8. There are no restrictions on the availability of information on the internet;

9. Individuals are adequately protected from government's using geospatial surveillance technology; and

10.Laws and policies encourage the use of industry standards that promote interoperability.
 
This list is still a work in progress. Therefore, please let me know if there are any items you would suggest adding or removing from this list.

6 comments:

John Milburn said...

Thank you for posting a policy framework Kevin. Can you please elaborate a little on 6? You may have to narrow down 'other types of technology' a little. An aluminum can and a small tactical nuke are both kinds of technology. I don't want the same distribution policy for both however.

. said...

Government treats geospatial information as infrastructure acknowledging its need for consistent maintenance and budgets or implements financing structures that support data maintenance.

Government implements both CIO and CTO positions at the highest level of government.

Kevin said...

John,

For instance, treating the collection of imagery from satellites different than the collection of aerial images. Or restricting making the collection of geolocation information from one source (sensor) than from another source.

John Milburn said...

I disagree with the statement "Government treats geospatial information as infrastructure acknowledging its need for consistent maintenance and budgets or implements financing structures that support data maintenance".


This may be true at the local and state level in some cases. However I don't believe this is true at the federal level. Consider the physical infrastructure for the United States road network if you will. Local, State and Federal entities all have a hand in maintaining the road network, receive funding to support their work and understand their roles. Now consider centerline data. Open sources, private sources, local, state and fed entities all maintain different copies of data covering the same jurisdiction. Do we each maintain a set of our own physical road infrastructure for our exclusive use?


The feds don't want to deal with state and local data. They lack the capacity for technical and political innovation that's necessary to make the vision of the NSDI a reality. Consider if you will that in order to get Indiana's spatial data integrated into the NSDI that it was necessary to bypass the NSGIC and the FGDC entirely (ref: http://geoplatform.ideascale.com/a/dtd/The-50-States-Initiative-guidelines-need-scrapped-and-rewritten/99477-10935). Why was that necessary?

John Milburn said...

In retrospect I think I took the comment from the unknown user out of context. Ironically my disagreement serves as a kind of acknowledgement of what they're suggesting (which initially I took as a statement of what they perceive currently exists). Sorry for any confusion.

. said...

How or what the Federal Government does to treat geospatial data as infrastructure is exactly what I think needs to happen. Let’s take your transportation for example. Treating geospatial data like transportation would mean that the Feds would supply incentives and minimum standards to the States. The States would use the incentives and apply the standards as well as add their own standards and actually create the data or accumulate from their county equivalents. Every State is different in how it handles data down to the county equivalents and the same is true for roads. The Federal Government supplies money and other incentives to the States to maintain the roads and the States maintain the Interstates and State roads, the local counties receive money from the State along with their own to maintain their local streets. This varies from county to county and State to State but it’s fairly similar. The point here is that the federal government does not do the work, nor do we want them to. But they become a repository and accumulator while supplying standards and incentives to the States/Local government to maintain the data.
The other reason I used the term infrastructure is to clarify that this is not a ‘thing’ to be bought. I don’t feel that the government fully realizes that this data needs to be the product of a process which is perpetuated. I know that a lot of the issue here is the rapid changes in technology that have made it seem more like a product because both process and data delivered have become obsolete in only a few years. A lot of this seems to be slowing down a bit and we have gotten a lot better at migrating to new systems. But still building the process here is more important than the product which is sure to change.