Steering Group Meeting 4th May 2012



OSM-GB Steering Group. 4th May 2012

Present:

S. Feldman, KnowWhere, OSM -GB Chair

J. Morley, NGI, OSM-GB Project Lead

A. Pourabdollah, NGI, OSM-GB Main Research Fellow

T. Mooney, NGI, OSM-GB Assistant Researcher

B.Chell, 1Spatial, GIS Consultant (Via teleconference)

C. Smith, EDINA at Edinburgh University

J. Rutler, Surrey Heath Borough Council

S. Larson, ESRI UK and OSM Contributor

T. Adams, Metropolitan Police Crime Mapping

Apologies:

A. Newman, DEFRA and UK Location Program

A.Alan, OSM

M. Daly, Cadcorp

G.Hart, Ordnance Survey

=Meeting Objective=

To further define the steering group, its purpose and objectives. The OSM-GB team are keen to enlist the help of professional GIS experts to help shape research principles, give direction and shaped the project and to channel and feedback issues and experiences. It is envisaged that the steering group will have representatives and provide feedback from the areas of central and local government, the academic community, the emergency services and technical providers.

Agenda
 ·       Introductions.

 ·       J.Morley to present project overview.

 ·       A. Pourabdollah to present a summary of the infrastructure and research so far.

 ·       Feedback from steering group members on the trials of the service so far and proposed services.

 ·       Set next set of targets and specific tasks.

   

   

= J.Morley - project overview.=

OSM-GB has two strands:

1.      Technical data objectives: the formal data quality improvement of OSM data via the rules catalogue and its conflation with open source ordnance survey data.

2.      Cultural objectives: the relationship between quality and usage (predominantly within the public sector) and research into what makes data more usable.

Academic research motivators for the OSM-GB product fall under three broad headings:

 ·       Authoritative: - the process of making the data more authoritative, i.e. the actual doing of the data quality and the reporting of the data quality changes. What is data quality, how it is measured and reported?

 ·<span style="font: 7.0pt &quot;Times New Roman&quot;">       Community: - the process of making the product usable by the community and potentially sustainable. Establishing what the community currently uses, what they would like to see as a product, what would encourage the take-up of the OSM-GB product and the long-term sustainability of the OSM-GB product - i.e. how is it going to pay for itself?

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">       Philosophy: - a research driven project and product that is intended to sit alongside the original OSM product and community, not replace the OSM product in any way, shape or form - and to promote further engagement (use and contribution) from the non-technical community.

Outlined Phase one progress (See previously circulated AP Phase one report) highlighting the following:

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">       Not all errors are fixable - for example missing attribute data.

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">       So far only a few thousand features have had rules applied.

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">       OSM-GB product updates are currently about 3 months behind OSM data as the focus of the project so far has been establishing and setting up the architecture and infrastructure to the service.

Also directed steering group members to the wiki page and blog for further project information and continuous updates.

SF further stressed the point that contributions to the wiki and the blog welcomed from the steering group.

   

   

   

   

   

=A. Pourabdollah - summary of the infrastructure and research so far.=

Amir talked through the system diagram, technologies used and project workflow as outlined in the previously circulated phase 1 report and also available on the wiki. Infrastructure development and implementation was the focus for the majority of phase 1. Data management that optimises the structure and available hardware is now being investigated and implemented. However, the development and application of the rules catalogue along with data quality assessment is core to the project.

AP conducted a demonstration showing the geometric corrections and findings so far. He also explained the rules catalogue and how the rules were applied to the data.

AP demonstrated how the original OSM attribute data tags have been grouped and subgroups into layers for the OSM-GB product. For example within the group/layer water there are further subgroups/layers such as lake, pond, river, stream, reservoir etc. It illustrated how this reduces the number of layers and makes navigating between layers more intuitive and easily understood. He explained how these layers are determined by the tagging structure of OSM data and the schema employed by Mapnik, but explained that these can also be customised.

All of the above is still in the early stages and underdevelopment and Amir stated that he welcomes feedback from the steering group.

= Feedback from steering group members on the trials of the service so far. =

<font color="#222222"><font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">                 JR queries co-ordinate transforms: at what point is the data transformed from Spherical Mercator to BNG - at the point of rendering or in one of the databases (in Oracle Spatial or when exporting from Oracle Spatial into PostGIS ). Suggested  Artem  <font color="#222222">    <font color="#222222">Pavlenko  <font color="#222222">, the original developer of    Mapnik  <font color="#222222">, may be able to help and he has already written some similar code.

The main contributors to the discussion were AP, JM and JR. They highlighted the following considerations and issues to be resolved around the co-ordinate transfer process:

It needs to be decided whether to apply the rules to Spherical Mercator or BNG data and how many products to supply. If errors are being fed back to the OSM community, they will we require the errors to be fed back to them in Spherical Mercator, therefore the rules need to be applied on the data held in the original Spherical Mercator format. However, there are multiple products to be produced, and the main users of the OSM-GB product will require data to be delivered as WFS vectors and/or WMS tiles in BNG and/or Spherical Mercator. Careful consideration is needed as to when to apply the transfer to avoid introducing ‘artificial’ error, i.e. error that is as a direct result or magnified/distorted during the data handling process.

BC pointed out that 1Spatial’s rules catalogue does not have a problem applying the rules at any stage in any co-ordinate; it automatically detects the spatial reference.

SF and TA reminded the steering group that the product needed to be usable and easily accessible to the end user, therefore needs to be kept simple. The end user needs to be able to easily access either WMS or WFS data at the click of a button and be confident that the data is readily available in the required schema and coordinate system (BNG the bulk of the public sector). TA stated that in his experience if the end user could not ‘pick up the data and run with it’ the product would be abandoned, no matter how good a product it developed into. SF concurred. In essence OMS-GB do not want to put off potential users right at the start. The other members of the steering group agreed.

TA showed steering group the difficulty he faced trying to access the OSM-GB product using MapInfo. He pointed out that in the public sector MapInfo was a highly utilised GIS package and if the end-user was unable to easily access the data they would revert to methods that worked and would be reluctant in the future to attempt to use the new product, no matter how good it was.

JM - proposed that the first target should be an easily accessible product for the public service in BNG in a layered structure that Geographical Information people understood and is intuitive. He stated that it was important to provide a range of services that was easy to use, but it was important for the University to address its own research agenda alongside this and for there to be a careful balancing of time. He did not want the research team to become ‘bogged down’ with the infrastructure and technological side of the project at the expense of researching the quality improvement side of things, for example what is data quality and how it relates to OSM rules etc. He reiterated that it was important to establish where to focus energies and that the project currently only has funding until April 2013. He stated it was important to add value to and validate the service to secure extra funding in the future.

AP and/or JM agreed to check if MapInfo was available to the University of Nottingham under the CHEST agreement, if not SF to approach MapInfo to provide a test licence.

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">                JR, SL and TA said they liked the layers for the OSM-GB product, stating that this was already an improvement in usability as this is not easily accomplished with the original OSM product for non-technical users. SL updated the steering group with regard to itoWorld, who are doing something similar, stating it might be beneficial to look at their work. 

AM acknowledged that there was still work on refining groups to do.

JM suggested that once Amir had refined the groups, it would be possible to create a tile cache to create and stack those tiles with transparent backgrounds so that the raster format could benefit from the clarity that layer provide.

SL stated that a shape file download would be useful. This would allow for more data analysis to be conducted by the end user and would potentially also take pressure off the WMS service.

JM suggested that in the future it should be possible to ’cookie cutter’ regions of the UK, by country or county etc.

A general discussion about the rules and the rules catalogue was undertaken. It was agreed that BC would publish a conceptual model explaining in natural language what the rules are and what they will do. It was agreed by the steering group that it was important that early adopters and the wider community understood the rules and were able to explain in natural language the sort of rules they might want the OSM-GB project to implement on the OSM data so that they might be able to feed suggestions of the kind of rules to apply to the data directly to the OSM-GB project. It was suggested that Andy Allan would be a good person to discuss how to feed errors back into the OSM community. BC agreed to produce guidelines on how to describe rules. This can be put on the wiki or blog to invite people to describe the rules they would like to see. He can then work with AM to establish which bits of the data are important and what rules are important. JM suggested a page either on the blog, wiki or as a forum entitled “what bugs you?” so that people can suggest what improvements they would like to see.

It was agreed that it was important to lower the barrier of entry to open/crowd sourced mapping information, and making the data easily accessible for use by the end user it would promote community engagement, usage and uptake - and hopefully will promote and encourage contribution to quality improvement and go part of the way to addressing the issue of completeness

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">                JM and JR raised the issue of change only updates and stable historical/archived snapshots of the improved data. JR inform the steering group that itoWorld maintain historical snapshots, but that in his experience industry only has a passing interest in historical data - they want more up-to-date stuff. He said he could appreciate that the academic community could potentially benefit from an archive of historical data. JM stated that at the moment storage space was not an issue. SF suggested that because the PostGIS database had the most up-to-date data, Oracle could store the archived data and data is used rollbacks. JM conceded that perhaps it was only a consideration if it transpired that the community was ‘crying out’ for the service, otherwise selection of data may be held for internal research. JR   - it's an interesting question to put the blog and/or questionnaire.

JR and CS pointed out that change only updates were quite a commitment for the end user, if they missed the update then they would have to download a completely new dataset anyway. In their opinion people would only access the data when they want it, few people would need, want or be bothered to maintain update. JR also said that given the time constraints and complexity of achieving change only updates, it might be better to focus their energies elsewhere at this point and potentially revisiting the future. SF stated that it was something that could be floated initially with early adopters and then monitor to see if there was demand service.

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">                JM floated the idea of conflating the OSM-GB product with Ordnance Survey open source data further geometric corrections. TA said that while this was a nice idea and very interesting, he felt it was more important to get the minimum viable product that can get people on board and engaged with OSM-GB. He suggested that if we were to aspire to get funding from April 2013, conflation could form part of that research. JM stated that he felt the conflation was part of the data validity process, and an interesting research question. If we successfully managed to make the data accessible to more people, used by more people and contributed to by more people and they could see that the data was being checked against something authoritative, at least in part, it would give them confidence to further use and contribute to the product? Would it create a positive feedback loop?

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">                TA the things he would like to see from the emergency services point of view are:

1.<span style="font: 7.0pt &quot;Times New Roman&quot;">      The ability to connect to the service without even having to think about it, if the end user had to configure the WMS server within a GIS in any way, they would not do it.

2.<span style="font: 7.0pt &quot;Times New Roman&quot;">      Need background mapping facility and access to different layers

3.<span style="font: 7.0pt &quot;Times New Roman&quot;">      WMS versus tiles: speed of the issue. The emergency services use Google map, which is felt to be fast, certainly faster than the current OSM-GB service. People will be lost before the project has really got started if it is too slow.

CS pointed out that this issue with Google maps was actually only perception of increased speed, that it was a natural fact clever rendering.

JM stated that by cleaning up the data and clever data management speed would be improved.

JR said it was important to establish what the problems with the OSM data were, what to do to it to clean it up and fix it and establish the data problems within the map base.

JR and SF felt that the OSM community should be approached as a priority to see what quality fixes they would like to see (i.e. what rules) and to engage them through the blog or other public communication medium. SF said it was important to contribute to OSM, not just leech off it and engaging with them to talk OSM-GB for a two-way exchange of information would be beneficial to both parties. He also highlighted to the steering group that as far as the OSM product goes there are two groups: the contributors, who are tech savvy and know how to contribute to fix ups, and everybody else - and they will include those who have not got over the technological hump and have not downloaded or used OSM data and/or have not heard or understood the concept of the OSM product and how it might benefit them all their business.

<font face="Symbol"> ·<span style="font: 7.0pt &quot;Times New Roman&quot;">                SF Map and front page need a search box

SF stated that early adopters can help the OSM-GB team decide where to focus energies and how to serve the products. JM suggested a questionnaire will be useful for this. He suggested a market survey of what specific objectives are needed and what services will attract people to use the product, and what quality assurances would they be looking for? 

=Summary of Targets and Tasks=

Contributions to the wiki and the blog welcomed from the steering group. If they require access, they will need to contact AP for permissions.

AP and JM to put a selection of slides used on line (Wiki or other).

First target to be an easily accessible product for the public, serving in BNG with a layered structure that Geographical Information people understood and is intuitive.

A questionnaire targeted at early adopters to establish the type of products in demand and how to serve them.

AP and/or JM agreed to check if MapInfo was available to the University of Nottingham under the CHEST agreement, if not SF to approach MapInfo to provide a test licence.

BC to produce a conceptual model explaining in natural language what the rules are and what they will do, and then to produce guidelines on how to describe rules. This can be put on the wiki or blog to invite people to describe the rules they would like to see. He can then work with AM to establish which bits of the data are important and what rules are important.

AP - construct search box for map and front page.

AP - “What Bugs You?” Page