Tag Archives: opendata

Raspberry Jam Big Birthday Weekend 2018 roundup

Post Syndicated from Ben Nuttall original https://www.raspberrypi.org/blog/big-birthday-weekend-2018-roundup/

A couple of weekends ago, we celebrated our sixth birthday by coordinating more than 100 simultaneous Raspberry Jam events around the world. The Big Birthday Weekend was a huge success: our fantastic community organised Jams in 40 countries, covering six continents!

We sent the Jams special birthday kits to help them celebrate in style, and a video message featuring a thank you from Philip and Eben:

Raspberry Jam Big Birthday Weekend 2018

To celebrate the Raspberry Pi’s sixth birthday, we coordinated Raspberry Jams all over the world to take place over the Raspberry Jam Big Birthday Weekend, 3-4 March 2018. A massive thank you to everyone who ran an event and attended.

The Raspberry Jam photo booth

I put together code for a Pi-powered photo booth which overlaid the Big Birthday Weekend logo onto photos and (optionally) tweeted them. We included an arcade button in the Jam kits so they could build one — and it seemed to be quite popular. Some Jams put great effort into housing their photo booth:



Here are some of my favourite photo booth tweets:

RGVSA on Twitter

PiParty photo booth @RGVSA & @ @Nerdvana_io #Rjam

Denis Stretton on Twitter

The @SouthendRPIJams #PiParty photo booth

rpijamtokyo on Twitter

PiParty photo booth

Preston Raspberry Jam on Twitter

Preston Raspberry Jam Photobooth #RJam #PiParty

If you want to try out the photo booth software yourself, find the code on GitHub.

The great Raspberry Jam bake-off

Traditionally, in the UK, people have a cake on their birthday. And we had a few! We saw (and tasted) a great selection of Pi-themed cakes and other baked goods throughout the weekend:






Raspberry Jams everywhere

We always say that every Jam is different, but there’s a common and recognisable theme amongst them. It was great to see so many different venues around the world filling up with like-minded Pi enthusiasts, Raspberry Jam–branded banners, and Raspberry Pi balloons!

Europe

Sergio Martinez on Twitter

Thank you so much to all the attendees of the Ikana Jam in Krakow past Saturday! We shared fun experiences, some of them… also painful 😉 A big thank you to @Raspberry_Pi for these global celebrations! And a big thank you to @hubraum for their hospitality! #PiParty #rjam

NI Raspberry Jam on Twitter

We also had a super successful set of wearables workshops using @adafruit Circuit Playground Express boards and conductive thread at today’s @Raspberry_Pi Jam! Very popular! #PiParty

Suzystar on Twitter

My SenseHAT workshop, going well! @SouthendRPiJams #PiParty

Worksop College Raspberry Jam on Twitter

Learning how to scare the zombies in case of an apocalypse- it worked on our young learners #PiParty @worksopcollege @Raspberry_Pi https://t.co/pntEm57TJl

Africa

Rita on Twitter

Being one of the two places in Kenya where the #PiParty took place, it was an amazing time spending the day with this team and getting to learn and have fun. @TaitaTavetaUni and @Raspberry_Pi thank you for your support. @TTUTechlady @mictecttu ch

GABRIEL ONIFADE on Twitter

@TheMagP1

GABRIEL ONIFADE on Twitter

@GABONIAVERACITY #PiParty Lagos Raspberry Jam 2018 Special International Celebration – 6th Raspberry-Pi Big Birthday! Lagos Nigeria @Raspberry_Pi @ben_nuttall #RJam #RaspberryJam #raspberrypi #physicalcomputing #robotics #edtech #coding #programming #edTechAfrica #veracityhouse https://t.co/V7yLxaYGNx

North America

Heidi Baynes on Twitter

The Riverside Raspberry Jam @Vocademy is underway! #piparty

Brad Derstine on Twitter

The Philly & Pi #PiParty event with @Bresslergroup and @TechGirlzorg was awesome! The Scratch and Pi workshop was amazing! It was overall a great day of fun and tech!!! Thank you everyone who came out!

Houston Raspi on Twitter

Thanks everyone who came out to the @Raspberry_Pi Big Birthday Jam! Special thanks to @PBFerrell @estefanniegg @pcsforme @pandafulmanda @colnels @bquentin3 couldn’t’ve put on this amazing community event without you guys!

Merge Robotics 2706 on Twitter

We are back at @SciTechMuseum for the second day of @OttawaPiJam! Our robot Mergius loves playing catch with the kids! #pijam #piparty #omgrobots

South America

Javier Garzón on Twitter

Así terminamos el #Raspberry Jam Big Birthday Weekend #Bogota 2018 #PiParty de #RaspberryJamBogota 2018 @Raspberry_Pi Nos vemos el 7 de marzo en #ArduinoDayBogota 2018 y #RaspberryJamBogota 2018

Asia

Fablab UP Cebu on Twitter

Happy 6th birthday, @Raspberry_Pi! Greetings all the way from CEBU,PH! #PiParty #IoTCebu Thanks @CebuXGeeks X Ramos for these awesome pics. #Fablab #UPCebu

福野泰介 on Twitter

ラズパイ、6才のお誕生日会スタート in Tokyo PCNブースで、いろいろ展示とhttps://t.co/L6E7KgyNHFとIchigoJamつないだ、こどもIoTハッカソンmini体験やってます at 東京蒲田駅近 https://t.co/yHEuqXHvqe #piparty #pipartytokyo #rjam #opendataday

Ren Camp on Twitter

Happy birthday @Raspberry_Pi! #piparty #iotcebu @coolnumber9 https://t.co/2ESVjfRJ2d

Oceania

Glenunga Raspberry Pi Club on Twitter

PiParty photo booth

Personally, I managed to get to three Jams over the weekend: two run by the same people who put on the first two Jams to ever take place, and also one brand-new one! The Preston Raspberry Jam team, who usually run their event on a Monday evening, wanted to do something extra special for the birthday, so they came up with the idea of putting on a Raspberry Jam Sandwich — on the Friday and Monday around the weekend! This meant I was able to visit them on Friday, then attend the Manchester Raspberry Jam on Saturday, and finally drop by the new Jam at Worksop College on my way home on Sunday.

Ben Nuttall on Twitter

I’m at my first Raspberry Jam #PiParty event of the big birthday weekend! @PrestonRJam has been running for nearly 6 years and is a great place to start the celebrations!

Ben Nuttall on Twitter

Back at @McrRaspJam at @DigInnMMU for #PiParty

Ben Nuttall on Twitter

Great to see mine & @Frans_facts Balloon Pi-Tay popper project in action at @worksopjam #rjam #PiParty https://t.co/GswFm0UuPg

Various members of the Foundation team attended Jams around the UK and US, and James from the Code Club International team visited AmsterJam.

hackerfemo on Twitter

Thanks to everyone who came to our Jam and everyone who helped out. @phoenixtogether thanks for amazing cake & hosting. Ademir you’re so cool. It was awesome to meet Craig Morley from @Raspberry_Pi too. #PiParty

Stuart Fox on Twitter

Great #PiParty today at the @cotswoldjam with bloody delicious cake and lots of raspberry goodness. Great to see @ClareSutcliffe @martinohanlon playing on my new pi powered arcade build:-)

Clare Sutcliffe on Twitter

Happy 6th Birthday @Raspberry_Pi from everyone at the #PiParty at #cotswoldjam in Cheltenham!

Code Club on Twitter

It’s @Raspberry_Pi 6th birthday and we’re celebrating by taking part in @amsterjam__! Happy Birthday Raspberry Pi, we’re so happy to be a part of the family! #PiParty

For more Jammy birthday goodness, check out the PiParty hashtag on Twitter!

The Jam makers!

A lot of preparation went into each Jam, and we really appreciate all the hard work the Jam makers put in to making these events happen, on the Big Birthday Weekend and all year round. Thanks also to all the teams that sent us a group photo:

Lots of the Jams that took place were brand-new events, so we hope to see them continue throughout 2018 and beyond, growing the Raspberry Pi community around the world and giving more people, particularly youths, the opportunity to learn digital making skills.

Philip Colligan on Twitter

So many wonderful people in the @Raspberry_Pi community. Thanks to everyone at #PottonPiAndPints for a great afternoon and for everything you do to help young people learn digital making. #PiParty

Special thanks to ModMyPi for shipping the special Raspberry Jam kits all over the world!

Don’t forget to check out our Jam page to find an event near you! This is also where you can find free resources to help you get a new Jam started, and download free starter projects made especially for Jam activities. These projects are available in English, Français, Français Canadien, Nederlands, Deutsch, Italiano, and 日本語. If you’d like to help us translate more content into these and other languages, please get in touch!

PS Some of the UK Jams were postponed due to heavy snowfall, so you may find there’s a belated sixth-birthday Jam coming up where you live!

S Organ on Twitter

@TheMagP1 Ours was rescheduled until later in the Spring due to the snow but here is Babbage enjoying the snow!

The post Raspberry Jam Big Birthday Weekend 2018 roundup appeared first on Raspberry Pi.

Querying OpenStreetMap with Amazon Athena

Post Syndicated from Seth Fitzsimmons original https://aws.amazon.com/blogs/big-data/querying-openstreetmap-with-amazon-athena/

This is a guest post by Seth Fitzsimmons, member of the 2017 OpenStreetMap US board of directors. Seth works with clients including the Humanitarian OpenStreetMap Team, Mapzen, the American Red Cross, and World Bank to craft innovative geospatial solutions.

OpenStreetMap (OSM) is a free, editable map of the world, created and maintained by volunteers and available for use under an open license. Companies and non-profits like Mapbox, Foursquare, Mapzen, the World Bank, the American Red Cross and others use OSM to provide maps, directions, and geographic context to users around the world.

In the 12 years of OSM’s existence, editors have created and modified several billion features (physical things on the ground like roads or buildings). The main PostgreSQL database that powers the OSM editing interface is now over 2TB and includes historical data going back to 2007. As new users join the open mapping community, more and more valuable data is being added to OpenStreetMap, requiring increasingly powerful tools, interfaces, and approaches to explore its vastness.

This post explains how anyone can use Amazon Athena to quickly query publicly available OSM data stored in Amazon S3 (updated weekly) as an AWS Public Dataset. Imagine that you work for an NGO interested in improving knowledge of and access to health centers in Africa. You might want to know what’s already been mapped, to facilitate the production of maps of surrounding villages, and to determine where infrastructure investments are likely to be most effective.

Note: If you run all the queries in this post, you will be charged approximately $1 based on the number of bytes scanned. All queries used in this post can be found in this GitHub gist.

What is OpenStreetMap?

As an open content project, regular OSM data archives are made available to the public via planet.openstreetmap.org in a few different formats (XML, PBF). This includes both snapshots of the current state of data in OSM as well as historical archives.

Working with “the planet” (as the data archives are referred to) can be unwieldy. Because it contains data spanning the entire world, the size of a single archive is on the order of 50 GB. The format is bespoke and extremely specific to OSM. The data is incredibly rich, interesting, and useful, but the size, format, and tooling can often make it very difficult to even start the process of asking complex questions.

Heavy users of OSM data typically download the raw data and import it into their own systems, tailored for their individual use cases, such as map rendering, driving directions, or general analysis. Now that OSM data is available in the Apache ORC format on Amazon S3, it’s possible to query the data using Athena without even downloading it.

How does Athena help?

You can use Athena along with data made publicly available via OSM on AWS. You don’t have to learn how to install, configure, and populate your own server instances and go through multiple steps to download and transform the data into a queryable form. Thanks to AWS and partners, a regularly updated copy of the planet file (available within hours of OSM’s weekly publishing schedule) is hosted on S3 and made available in a format that lends itself to efficient querying using Athena.

Asking questions with Athena involves registering the OSM planet file as a table and making SQL queries. That’s it. Nothing to download, nothing to configure, nothing to ingest. Athena distributes your queries and returns answers within seconds, even while querying over 9 years and billions of OSM elements.

You’re in control. S3 provides high availability for the data and Athena charges you per TB of data scanned. Plus, we’ve gone through the trouble of keeping scanning charges as small as possible by transcoding OSM’s bespoke format as ORC. All the hard work of transforming the data into something highly queryable and making it publicly available is done; you just need to bring some questions.

Registering Tables

The OSM Public Datasets consist of three tables:

  • planet
    Contains the current versions of all elements present in OSM.
  • planet_history
    Contains a historical record of all versions of all elements (even those that have been deleted).
  • changesets
    Contains information about changesets in which elements were modified (and which have a foreign key relationship to both the planet and planet_history tables).

To register the OSM Public Datasets within your AWS account so you can query them, open the Athena console (make sure you are using the us-east-1 region) to paste and execute the following table definitions:

planet

CREATE EXTERNAL TABLE planet (
  id BIGINT,
  type STRING,
  tags MAP<STRING,STRING>,
  lat DECIMAL(9,7),
  lon DECIMAL(10,7),
  nds ARRAY<STRUCT<ref: BIGINT>>,
  members ARRAY<STRUCT<type: STRING, ref: BIGINT, role: STRING>>,
  changeset BIGINT,
  timestamp TIMESTAMP,
  uid BIGINT,
  user STRING,
  version BIGINT
)
STORED AS ORCFILE
LOCATION 's3://osm-pds/planet/';

planet_history

CREATE EXTERNAL TABLE planet_history (
    id BIGINT,
    type STRING,
    tags MAP<STRING,STRING>,
    lat DECIMAL(9,7),
    lon DECIMAL(10,7),
    nds ARRAY<STRUCT<ref: BIGINT>>,
    members ARRAY<STRUCT<type: STRING, ref: BIGINT, role: STRING>>,
    changeset BIGINT,
    timestamp TIMESTAMP,
    uid BIGINT,
    user STRING,
    version BIGINT,
    visible BOOLEAN
)
STORED AS ORCFILE
LOCATION 's3://osm-pds/planet-history/';

changesets

CREATE EXTERNAL TABLE changesets (
    id BIGINT,
    tags MAP<STRING,STRING>,
    created_at TIMESTAMP,
    open BOOLEAN,
    closed_at TIMESTAMP,
    comments_count BIGINT,
    min_lat DECIMAL(9,7),
    max_lat DECIMAL(9,7),
    min_lon DECIMAL(10,7),
    max_lon DECIMAL(10,7),
    num_changes BIGINT,
    uid BIGINT,
    user STRING
)
STORED AS ORCFILE
LOCATION 's3://osm-pds/changesets/';

 

Under the Hood: Extract, Transform, Load

So, what happens behind the scenes to make this easier for you? In a nutshell, the data is transcoded from the OSM PBF format into Apache ORC.

There’s an AWS Lambda function (running every 15 minutes, triggered by CloudWatch Events) that watches planet.openstreetmap.org for the presence of weekly updates (using rsync). If that function detects that a new version has become available, it submits a set of AWS Batch jobs to mirror, transcode, and place it as the “latest” version. Code for this is available at osm-pds-pipelines GitHub repo.

To facilitate the transcoding into a format appropriate for Athena, we have produced an open source tool, OSM2ORC. The tool also includes an Osmosis plugin that can be used with complex filtering pipelines and outputs an ORC file that can be uploaded to S3 for use with Athena, or used locally with other tools from the Hadoop ecosystem.

What types of questions can OpenStreetMap answer?

There are many uses for OpenStreetMap data; here are three major ones and how they may be addressed using Athena.

Case Study 1: Finding Local Health Centers in West Africa

When the American Red Cross mapped more than 7,000 communities in West Africa in areas affected by the Ebola epidemic as part of the Missing Maps effort, they found themselves in a position where collecting a wide variety of data was both important and incredibly beneficial for others. Accurate maps play a critical role in understanding human communities, especially for populations at risk. The lack of detailed maps for West Africa posed a problem during the 2014 Ebola crisis, so collecting and producing data around the world has the potential to improve disaster responses in the future.

As part of the data collection, volunteers collected locations and information about local health centers, something that will facilitate treatment in future crises (and, more importantly, on a day-to-day basis). Combined with information about access to markets and clean drinking water and historical experiences with natural disasters, this data was used to create a vulnerability index to select communities for detailed mapping.

For this example, you find all health centers in West Africa (many of which were mapped as part of Missing Maps efforts). This is something that healthsites.io does for the public (worldwide and editable, based on OSM data), but you’re working with the raw data.

Here’s a query to fetch information about all health centers, tagged as nodes (points), in Guinea, Sierra Leone, and Liberia:

SELECT * from planet
WHERE type = 'node'
  AND tags['amenity'] IN ('hospital', 'clinic', 'doctors')
  AND lon BETWEEN -15.0863 AND -7.3651
  AND lat BETWEEN 4.3531 AND 12.6762;

Buildings, as “ways” (polygons, in this case) assembled from constituent nodes (points), can also be tagged as medical facilities. In order to find those, you need to reassemble geometries. Here you’re taking the average of all nodes that make up a building (which will be the approximate center point, which is close enough for this purpose). Here is a query that finds both buildings and points that are tagged as medical facilities:

-- select out nodes and relevant columns
WITH nodes AS (
  SELECT
    type,
    id,
    tags,
    lat,
    lon
  FROM planet
  WHERE type = 'node'
),
-- select out ways and relevant columns
ways AS (
  SELECT
    type,
    id,
    tags,
    nds
  FROM planet
  WHERE type = 'way'
    AND tags['amenity'] IN ('hospital', 'clinic', 'doctors')
),
-- filter nodes to only contain those present within a bounding box
nodes_in_bbox AS (
  SELECT *
  FROM nodes
  WHERE lon BETWEEN -15.0863 AND -7.3651
    AND lat BETWEEN 4.3531 AND 12.6762
)
-- find ways intersecting the bounding box
SELECT
  ways.type,
  ways.id,
  ways.tags,
  AVG(nodes.lat) lat,
  AVG(nodes.lon) lon
FROM ways
CROSS JOIN UNNEST(nds) AS t (nd)
JOIN nodes_in_bbox nodes ON nodes.id = nd.ref
GROUP BY (ways.type, ways.id, ways.tags)
UNION ALL
SELECT
  type,
  id,
  tags,
  lat,
  lon
FROM nodes_in_bbox
WHERE tags['amenity'] IN ('hospital', 'clinic', 'doctors');

You could go a step further and query for additional tags included with these (for example, opening_hours) and use that as a metric for measuring “completeness” of the dataset and to focus on additional data to collect (and locations to fill out).

Case Study 2: Generating statistics about mapathons

OSM has a history of holding mapping parties. Mapping parties are events where interested people get together and wander around outside, gathering and improving information about sites (and sights) that they pass. Another form of mapping party is the mapathon, which brings together armchair and desk mappers to focus on improving data in another part of the world.

Mapathons are a popular way of enlisting volunteers for Missing Maps, a collaboration between many NGOs, education institutions, and civil society groups that aims to map the most vulnerable places in the developing world to support international and local NGOs and individuals. One common way that volunteers participate is to trace buildings and roads from aerial imagery, providing baseline data that can later be verified by Missing Maps staff and volunteers working in the areas being mapped.

(Image and data from the American Red Cross)

Data collected during these events lends itself to a couple different types of questions. People like competition, so Missing Maps has developed a set of leaderboards that allow people to see where they stand relative to other mappers and how different groups compare. To facilitate this, hashtags (such as #missingmaps) are included in OSM changeset comments. To do similar ad hoc analysis, you need to query the list of changesets, filter by the presence of certain hashtags in the comments, and group things by username.

Now, find changes made during Missing Maps mapathons at George Mason University (using the #gmu hashtag):

SELECT *
FROM changesets
WHERE regexp_like(tags['comment'], '(?i)#gmu');

This includes all tags associated with a changeset, which typically include a mapper-provided comment about the changes made (often with additional hashtags corresponding to OSM Tasking Manager projects) as well as information about the editor used, imagery referenced, etc.

If you’re interested in the number of individual users who have mapped as part of the Missing Maps project, you can write a query such as:

SELECT COUNT(DISTINCT uid)
FROM changesets
WHERE regexp_like(tags['comment'], '(?i)#missingmaps');

25,610 people (as of this writing)!

Back at GMU, you’d like to know who the most prolific mappers are:

SELECT user, count(*) AS edits
FROM changesets
WHERE regexp_like(tags['comment'], '(?i)#gmu')
GROUP BY user
ORDER BY count(*) DESC;

Nice job, BrokenString!

It’s also interesting to see what types of features were added or changed. You can do that by using a JOIN between the changesets and planet tables:

SELECT planet.*, changesets.tags
FROM planet
JOIN changesets ON planet.changeset = changesets.id
WHERE regexp_like(changesets.tags['comment'], '(?i)#gmu');


Using this as a starting point, you could break down the types of features, highlight popular parts of the world, or do something entirely different.

Case Study 3: Building Condition

With building outlines having been produced by mappers around (and across) the world, local Missing Maps volunteers (often from local Red Cross / Red Crescent societies) go around with Android phones running OpenDataKit  and OpenMapKit to verify that the buildings in question actually exist and to add additional information about them, such as the number of stories, use (residential, commercial, etc.), material, and condition.

This data can be used in many ways: it can provide local geographic context (by being included in map source data) as well as facilitate investment by development agencies such as the World Bank.

Here are a collection of buildings mapped in Dhaka, Bangladesh:

(Map and data © OpenStreetMap contributors)

For NGO staff to determine resource allocation, it can be helpful to enumerate and show buildings in varying conditions. Building conditions within an area can be a means of understanding where to focus future investments.

Querying for buildings is a bit more complicated than working with points or changesets. Of the three core OSM element types—node, way, and relation, only nodes (points) have geographic information associated with them. Ways (lines or polygons) are composed of nodes and inherit vertices from them. This means that ways must be reconstituted in order to effectively query by bounding box.

This results in a fairly complex query. You’ll notice that this is similar to the query used to find buildings tagged as medical facilities above. Here you’re counting buildings in Dhaka according to building condition:

-- select out nodes and relevant columns
WITH nodes AS (
  SELECT
    id,
    tags,
    lat,
    lon
  FROM planet
  WHERE type = 'node'
),
-- select out ways and relevant columns
ways AS (
  SELECT
    id,
    tags,
    nds
  FROM planet
  WHERE type = 'way'
),
-- filter nodes to only contain those present within a bounding box
nodes_in_bbox AS (
  SELECT *
  FROM nodes
  WHERE lon BETWEEN 90.3907 AND 90.4235
    AND lat BETWEEN 23.6948 AND 23.7248
),
-- fetch and expand referenced ways
referenced_ways AS (
  SELECT
    ways.*,
    t.*
  FROM ways
  CROSS JOIN UNNEST(nds) WITH ORDINALITY AS t (nd, idx)
  JOIN nodes_in_bbox nodes ON nodes.id = nd.ref
),
-- fetch *all* referenced nodes (even those outside the queried bounding box)
exploded_ways AS (
  SELECT
    ways.id,
    ways.tags,
    idx,
    nd.ref,
    nodes.id node_id,
    ARRAY[nodes.lat, nodes.lon] coordinates
  FROM referenced_ways ways
  JOIN nodes ON nodes.id = nd.ref
  ORDER BY ways.id, idx
)
-- query ways matching the bounding box
SELECT
  count(*),
  tags['building:condition']
FROM exploded_ways
GROUP BY tags['building:condition']
ORDER BY count(*) DESC;


Most buildings are unsurveyed (125,000 is a lot!), but of those that have been, most are average (as you’d expect). If you were to further group these buildings geographically, you’d have a starting point to determine which areas of Dhaka might benefit the most.

Conclusion

OSM data, while incredibly rich and valuable, can be difficult to work with, due to both its size and its data model. In addition to the time spent downloading large files to work with locally, time is spent installing and configuring tools and converting the data into more queryable formats. We think Amazon Athena combined with the ORC version of the planet file, updated on a weekly basis, is an extremely powerful and cost-effective combination. This allows anyone to start querying billions of records with simple SQL in no time, giving you the chance to focus on the analysis, not the infrastructure.

To download the data and experiment with it using other tools, the latest OSM ORC-formatted file is available via OSM on AWS at s3://osm-pds/planet/planet-latest.orcs3://osm-pds/planet-history/history-latest.orc, and s3://osm-pds/changesets/changesets-latest.orc.

We look forward to hearing what you find out!

Градският транспорт и как данните биха ни помогнали да го подобрим

Post Syndicated from Боян Юруков original http://yurukov.net/blog/2017/danni-za-transporta/

Наскоро статус на Илиян Стоянов във Facebook ме подсети за това, че градския ни транспорт е една от сферите, в които липсват публични данни. Няколко града като София, Пловдив и Варна имат сайтове и дори app-ове, където човек може да провери разписание и планира маршрути. Самите данни за спирките и разписанието не са достъпни. Така не само не може друг да направи собствена услуга, но и не може да се анализира мрежата.

Затова седнах и първо отворих данните за спирките на споменатите три града. За тези в София вече писах във Facebook. В Бургас въпреки евро-проекта за интегриран транспорт, изглежда няма дори дигитална карта на спирките.

С тези прости данни направих бързи карти на спирките на София, Пловдив и Варна. Като спрете с мишката върху всяка точка, ще видите името ѝ. Вляво има бутон, с който може да ги разглеждате на цял екран.

Скриптовете и самите данни за спирките публикувах в Github. Ще ги намерите на страницата ми с Gist-ове.

Транспортът във Варна

Във Варна, всъщност, данните дори не са налични от общината, а от частния проект varnatraffic.com на Мап Софт. Той е и единственият, който намерих да показва местоположението на автобусите в реално време. Използвах данните им на база съобщение на сайта от преди две години, че предоставят всичко свободно като отворени данни.

За да илюстрирам колко е полезна тази информация, свалям вече седмица местоположението на всички автобуси в града. За този период събрах около 650 хиляди точки с различни параметри – номер на автобуса, предишна и следваща спирка, оставащо разстояние до спирката, закъснение. Следните три карти показват различен поглед над събраните данни.

Първата карта разглежда движението за седмицата между 21-ви и 28-ми март по часове и колко автобуси са били по улиците на града. В червено са доста натоварени отсечки, където много автобуси са се движели през дадения час. Картата показва как се увеличава и намалява този трафик в различните части на деня, както и през почивните дни. В неделя не се забелязва по-малко натоварване, за което вероятно допринасят и провелите се тогава избори.

Следващата карта се концентрира само върху понеделник, 27-ми март. Показва в детайли движението на всеки един автобус. В червено са отбелязани тези, които закъсняват повече от 5 мин. Забелязва се как между 7 и 8:30 вечерта много от автобусите закъсняват. Виждат се ясно и местата, където автобусите спират за почивки.

Тъй като имаме закъсненията преди всяка спирка, може да анализираме и каква е вероятността да се чака на нея. Може също да разделим тази оценка по часове. Последната карта показва именно това. Анализът се базира само на данните от последните 7-8 дни. Пренебрегнете посочената дата в картата – часът е важен. Инструментът не позволява показването са на час.

В зелено са спирките, на които в конкретната част от деня се чака не повече от 15 секунди. В жълто са тези до 30 секунди. В гамата на червено са тези със закъснение между минута и час. Отново се вижда колко голямо средно закъснение има в различни часове от дена и части на града.

В някои случаи включвам и автобусите пристигнали с няколко минути по-рано – това също се счита за отклонение, тъй като някои пътници биха го изпуснали. Редовни такива показатели сочат към неоптимално разписание на даденото място и час. Такива са 26% от събраните точки за движението на градския транспорт. В 8.7% от времето, автобусите са подранявали с повече от 3 минути. В други 50% автобусите са закъснявали с повече от 20 секунди.

Публичността не е услуга

Публичността на която и да е информация не е услуга, която се представя от администрация или частна компания на обществото. Това е неизменна част от прозрачността, отчетността и социалната отговорност. За държавната и местната администрация отворените данни са още едно ниво на инфраструктура. Доскоро говорихме само за магистрали. В последните години започна все повече да се възприема и интернет свързаността като инфраструктура, при това не по-малко съществена за бизнеса. Информацията и най-вече тази в отворен формат придобива все по-голяма важност по аналогичен начин. Данните идващи от частните компании следва да допълнят тази картина и са новата дефиниция на социална отговорност, която често си приписват.

Това, което показах с данните от само няколко дни движение в един град, не са просто шарени карти. Това е илюстрация какво може да се направи за час-два работа, а не крайната цел. Информацията в момента се използва само за улеснение на пътуващите. Съберем ли всичко заедно за целия транспорт и за голям период, се отварят много възможности. Може да се открият проблемни кръстовища, да се подобрява графика, да се оптимизира движението на пътищата и интервала на светофарите. Дори само координатите на спирките може да се използват, за да се открият най-„изолираните“ части от градовете и да се направи карта на най-лошо свързаните региони.

Обединявайки тези данни с масиви за трафика на коли, цените на имотите, координатите на училища, градини и болници, за схемата на почистване на улиците и прочие може да позволи много по-добро градско планиране. По-важното обаче, ще позволи на частни компании и неправителствени организации да изградят приложения използващи данните по различен начин. Най-лесното би било да се направят по-добри приложения за планиране на маршрут с градския транспорт. Сайтовете за недвижими имоти биха давали по-добра информация за свързаността на имота. Родителите биха могли по-лесно да откриват градини и ясли, които са привидно отдалечени, но биха били достигнати лесно с транспорт от дома или офиса им.

Всичко това би помогнало да се направят градовете по-добри и да се използва публичния транспорт повече допринасайки за намаляване на трафика и замърсяването. За съжаление, интуицията на повечето чиновници и поддържащи такива масиви от данни е, че информацията е тяхна собственост и ако бъде публикувана „някой може да я използва“. Това е реакцията, която съм получавал най-често от агенции и общини. Забравя се, че всъщност вече сме платили с данъците си за събирането на всеки информационен ресурс. Забравя се и че целта на всички тези регистри и информационни системи е именно информацията да е достъпна. При тези мащаби с индивидуални справки, PDF-и и снимки на документи това просто не става.

За щастие, вече е в сила изискването, че всички публични данни във всяка нова система на администрацията трябва да са налични като отворени данни. Следва само да следим това да се спазва и да използваме тези ресурси. Съществуват обаче много други стари системи, за които трябва да натискаме да се отворят. Координатите на спирките и автобусите градския транспорт е само един пример. Друг пример са координатите в реално време на снегорини и камиони чистещи улиците зимно време. Общините ги следят, но не публикуват информацията. Друг пример са адресите в градовете, анонимизирани и агрегирани данни от НАП за плащанията на пос терминали и такива от МВР за престъпления.

Тези примери спадат към дефиницията на big data. Не са просто полезни за гражданите и бизнеса, а информация, която самите институции често не успяват да обменят помежду си или дори да анализират. Затова всичко описано до тук повишава не само прозрачността, но и ефективно постига аспекти от така нужната структурна реформа на администрацията ни.

Жорж Ганчев безуспешно опита да скрие миналото си

Post Syndicated from Боян Юруков original http://yurukov.net/blog/2016/ganchev-krie-ds-minaloto-si/

Преди три седмици получих мейл от Google заради един от сайтовете ми – opendata.yurukov.net. Уведомиха ме, че някой е поискал при търсене на името му да бъде скрит един конкретен резултат – отворените данни за сътрудниците на Държавна сигурност. Макар да не съм ги обновявал от няколко години, те съдържат всички данни за около 5000 агента и информатори осветени от Комисията по досиетата.

Мейлът от Google е във връзка с т.н. механизъм “Правото да бъдеш забравен”. Той дава възможност на всеки гражданин на ЕС да иска от търсачките да не показват определени детайли за него или нея. Пример за това биха били неприятни снимки споделени от познати или новинарски статии показващи имената и лицата на жертви на насилие. В България имаме достатъчно примери на журналистически своеволия, които си просят да бъдат блокирани от потърпевшите. Пейо писа по-подробно за този механизъм преди две години.

Агентурни номера

Проблемът е, че този механизъм се експлоатира за не толкова чисти цели. В моя случай говорим за данни, които са публични със специален закон и ясната цел обществото да узнае кои са сътрудниците на ДС. Преди време отворих данните именно, за да е по-лесно търсенето. По-пълен списък с имената, но с по-малко данни, ще намерите отскоро на портала за отворени данни на правителството. Опитът на някого да скрие името си по такъв странен начин прави още по-интересно кой е той или тя.

g

Макар да не се споменава в мейла от кого идва искането, оказва се, че все пак може да разберем. В списъка има 4671 уникални осветени имена и още над 3000 имена на агенти и вербовчици. Започнах с имената на сътрудниците. Написах скрипт, който да ги търси в Google и да проверява дали отворените ми данни са сред резултатите. Търсачката има ограничение от 100 безплатни търсения на ден, така че отне време докато обработи значителен дял от имената.

И печелившият е…

Днес получих резултат. Оказа се, че с голяма вероятност човекът зад искането към Google да е Жорж Ганчев. Ако не сте забелязали, той е кандидат за президент с номер 5 бюлетината. При търсене на каквато и да е комбинация на старото или новото му име (преди се е казвал Георги Ганчев Петрушев) не излиза нищо от списъка ми със сътрудници. По принципа на изключване това означава, че именно той се е опитал да скрие миналото си на сътрудник. Странното е, че все пак откриваме сред резултатите страницата на самата Комисия. Причината най-вероятно е, че Google са му отказали да премахнат онзи резултат.

gg

Решението на Комисията по досиетата ще намерите на сайта им. Жорж Ганчев е бил сътрудник към Второ главно управление на ДС между 1970 и 1990 г. с псевдоним “Жорж”, който изглежда е възприел като лично име след това. Вербуван е от Михаил Михайлов, който е също осветлен от Комисията в качеството му на началник отдел в МВР до 1990-та.

Не може да сме на 100% сигурни в този резултат обаче, защото Google няма право да потвърди. Няма друго обяснение имената на Ганчев да не излизат при търсене. Ако друг беше подал точно това конкретно заявление, щях да съм получил подобен мейл и за Ганчев по-рано. Така при липса на по-просто обяснение, остава единствено отговорът, че той и предизборният му щаб си мислят, че може да скрият миналото му.

Важен механизъм за жертви

Според данните на Google от 2014-та до сега от българи са постъпили запитвания за премахване на почти 8000 адреса от търсачката. Това включва единствено частни лица като Ганчев, които са искали да скрият нещо за себе си. Под 1/4 от обработените са били наистина премахнати.

Важно е да се разбере, че механизмът на “Правото да бъдеш забравен” е важен за жертви на насилие, експлоатация или тормоз. В наше време информацията е всичко и безпринципното разбиване на личното пространство води до необратими последствия за често невинни хора. Затова не може в никакъв начин да кажем, че голяма част от тези 8000 заявки са нямали легитимни причини за премахване. Всеки може да подаде такова заявление, ако смята, че има право.

От друга страна, ако имате сайт и искате да получавате такива и други известия от Google, трябва да се регистрирате в Webmaster инструмента им. Там освен такива сигнали има доста информация какви проблеми има сайта ви при търсене и как може да е оптимизира.

Нека да им припомним

За да защитим този механизъм обаче, трябва да покажем недостатъците му. В този случай Жорж Ганчев с голяма степен на сигурност се е опитал да скрие миналото си от избирателите в качеството си на кандидат за президент. Изглежда иска да забрави.

Аз предлагам да му припомним. Призовавам всички да му пишем с текст “Спомняте ли си, че 20 години сте били в ДС?” Мейли, съобщения и постове във Facebook, SMS-и, ако му имате телефоните, въпроси по време на интервюта в рамките на предизборната кампания.

Всъщност, защо да се ограничаваме до него? Има още трима участници в надпреварата, които навярно също си мислят, че ще забравим миналото им на сътрудници на ДС. Нека припомним на всички тях, че си спомняме.

2016-04-22

Post Syndicated from Vasil Kolev original https://vasil.ludost.net/blog/?p=3300

Трябва да пиша по-редовно, да не се получава миш-маш като тоя по-долу.

Както обикновено, ми върви на дебъгване. В последната седмица от по-странните неща се сещам за:
– build на android image (за нещо, правено и писано от (некадърни) китайци);
– Java/groovy;
– Python;
– И нормалното количество VoIP бози.
За да завърша картинката, обмислям да седна да подкарам VAX-а, който виси в initLab.

Тая вечер ходих на концерт на “band H.”, хора, които свирят Tool. Прилично се справиха, въпреки че им куцаше ритъма на моменти (което не е учудващо, Tool са учудващо гадни за свирене).
(по някаква причина в същия ден имаше 3 концерта – band H., Smallman и Irfan, не беше лесен избора)
(random човек ме разпозна на концерта и каза колко се радва на разните проекти като initLab, дето правим)

Седнах да подкарвам най-накрая сертификати от letsencrypt за нещата по marla, и успях да наслагам на половината, преди да ме удари resource limit-а при тях. Следващата седмица ще ги довърша. Разписах нещата с acme-tiny, базирано на нещо, което Петко беше драснал за лаба, оказва се сравнително просто (ако config-а е подреден както трябва) да се parse-ва apache config-а и да се смята какви точно сертификати да се генерират за кого.
(открих кофа неща, които вече не се host-ват при мен и ги почистих)

Събрал съм резултатите от теста на FOSDEM-ската техника (сравнение на запис на stream-а и encode-нат резултат, от нашия и от FOSDEM-ския setup), и като цяло с още малко пипване това може да се окаже достатъчно лесно за по-малки конференции (на които не си влачим 6-7-8 човека от екипа).

На opendata.government.bg тия дни пак качиха нещо интересно (тоя път – целия търговски регистър от 2008ма досега) и пак претовариха нещастната виртуалка (която е един debian в/у microsoft hyper-v). Обмислям някаква магия да може да преживява такива неща по-лесно, щото не се очаква да намалеят интересните данни.

За който се интересува, върви световното първенство по snooker, прилично забавно е. Тия дни пътувахме в метрото и tether-нати през телефона ми и с един таблет си гледахме вървящия мач…
(да живее технологията)

И не си спомням нещо друго да ми се е случвало.

Българчетата родени в чужбина и новата ми най-любима карта

Post Syndicated from Боян Юруков original http://feedproxy.google.com/~r/yurukov-blog/~3/GpvuNlm2HdM/

bmap10
Картата, която виждате тук, показва за 60 секунди всички българчета родени в чужбина за последните 10 години – 96653 деца в целия свят. Тази карта е най-любимата ми до сега по няколко причини. Първата е, че показва данни, които не може да видим никъде в общественото пространство. Втората е, че реално не е истинска – поне не изцяло. Третата причина е най-важната – как точно я съставих. Не на последно място е и факта, че просто изглежда яко.
Защо я направих?
Преди 3 месеца с помощта на хора от Twitter взех данните за българчетата родени в чужбина. За да сме по-точни, справката показва по години и държави броят на децата родени между 2004 и 2013, на които е изваден български акт за раждане въз основа акт от друга държава. Това не са всички деца на българи зад граница, но за останалите няма как да знаем. Тогава само пуснах данните свободно в мрежата, но не направих карта. Проблемът беше, че държавите в справката на ГРАО бяха записани с нестандарни имена.

Първата карта с ражданията
Миналия петък седнах и попълних на ръка трибуквените ISO кодове на всички държави. Това ми позволи да направя тази карта, снимка на която виждате горе. Картата е доста обикновенна и показва в различни цветове държавите, където най-много българи са имали деца за тези 10 години. Все пак е интересна, защото дава възможност да се видят точната бройка за всяка страна. Нещо обаче липсва в нея. Макар цялата информация да е пред нас, картата си е чисто статистическа и малко суха.
Затова реших да заема подхода на Twitter. Те правят карти с tweet-ове покрай големи събития. Картите им показват точка всеки път когато някой някъде пише за избори, например. Така в рамките на няколко секунди може да видим как цели държави избухват в коментари по дадена тема. Исках да направя същото за ражданията – да покажа по една такава точка за всяко раждане в чужбина. Проблемът обаче е, че реално нямам точните места и дата на раждане на всяко бебе – само бройката. Тук стигаме до любимата ми част от проекта – как всъщност направих картата.

4 набора от данни в едно
Набор от данни (или dataset) е всяка таблица, справка, географски данни или каквото и да е, което може да участва в анализ. Първият, който използвах, е справката от ГРАО. Имах вече ражданията по години и можех по тях да интерполирам приблизително колко са ражданията във всеки ден от годината. Тук виждате извадката за Испания:
Натисни за по-голяма снимка
Знам обаче, че жените не раждат равномерно през годината – лятото обикновенно има пик. Вместо да търся статистика за всяка държава поотделно, се обърнах към българския регистър за ражданията. Отворих данните от него преди време и от тях извадих индекс за всеки месец от годината. Това е вторият набор от данни.
Натисни за по-голяма снимка
Горната графика всъщност не е коректна, защото не взима нула за отправна точка на вертикалната скала. Следващата е правилната и ни показва, че разликите в месеците не са чак толкова големи. За по-голяма точност обаче ги използвах във визуализацията си.
Натисни за по-голяма снимка
Прилагайки тези индекси, получих долните цифри за Испания по месеци. Можех, разбира се, да умножа по полинома, за да няма скок от декември към януари, а плавен преход, но прецених, че тези стойности са достатъчно добри, а и навярно ще позволят да се забележи рязка промяна в ражданията там, където я има.
Натисни за по-голяма снимка
След като имах месеците, просто избрах случаен ден за всяко раждане. При 10 години ускорени в 60 секунди точната дата няма значение. Преди малко се сетих, че трябваше да завъртя индексите за южното полукулбо заради обърнатите сезони, но често казано не ми се занимава повече.
Къде са българите по света?
Следващата стъпка беше по-трудна – как да избера коодинатите. Очевидният изход е да се вземат случайни точки на територията на дадена държава. Това е относително лесно: взимам третия ми dataset – границите на държавите в geojson формат, избирам случайна точка между най-североизточната и най-югозападната точка (правоъгълните очертания) и проверявам дали е в реалните граници. Повтарям докато имам достатъчно точки за визуализацията. За целта използвах javascript и този модул заедно с моя имплементация специално за geojson стандарта. Ето как би изглеждал този подход за Испания:
Натисни за по-голяма снимка
Както сами виждате, точките са пръснати по цялата карта. Доста от тях са далеч от населени места, където би могло да има родени българчета. В някои държави маркерите биха попаднали в пустини и планини. Трябва да изберем точки близо до българските диаспори. За жалост, не знаем къде са те, затова решението би било да се вземе карта на гъстотата на населението и да се работи с тези данни. Тази за Испания изглежда така:
Източник: Wikipedia. Натисни за по-голяма снимка
Да се търсят такива за всички държави обаче не е практично, а и не може да се автоматизира извеждането на маркерите. Затова направих нещо друго – взех данните от Glasuvam.org (четвъртият dataset). Това е един мой проект, в който българи в чужбина се абонират за новини около изборите. За целта дават града, в който живеят. Не записвам точните им координати, а случайна точка в града, за да мога после да им кажа коя е най-близката до тях секция. В събота пуснах карта показваща регистрациите в сайта през годините, на която се вижда как те се увеличават месец преди всеки вот. Взех тези данни като отправни точки. Ето тези в Испания:
Натисни за по-голяма снимка
Новият алгоритъм избираше случайна точка на максимално 15 км. от регистрация в сайта за изборите. Отново проверявах дали са в границите, за да не се окаже някоя в морето. Така избрах колкото точки са ми нужни и получих много по-реалистично разпределение на ражданията.
Това е дори по-добър подход от този с гъстотата на населението, защото отчита къде реално има българи. За държавите, в които няма абонирали се, използвах предходния алгоритъм. Това не е проблем, тъй като почти всички останали са малки по размер и брой раждания. Ето резултата за Испания:
Натисни за по-голяма снимка
Написах три скрипта, които прилагат тези алгоритми, пуснах ги за всички държави и получих списък с дати и координати. Вкарах списъка в CartoDB и след няколко настройки получих новата карта на българчетата родени в чужбина.
Измислена, но не съвсем
Казват, че изкуството създава лъжа, за да покаже истината. Тази карта далеч не е изкуство, но аз я намирам за красива. Не ви лъжа като казвам, че това е карта на ражданията, защото най-малкото бройката е истинска. Датите и координатите са доста добро приближение. Дори да имахме истинските, надали можеше да ги публикуваме по този начин. Поне не с точните координати. В този смисъл, закръгляне на истинските координати и дати с цел опазване на анонимността на семействата би дало резултат, който е много близък до моята картата. В същото време, използването им по този начин не би добавило голяма стойност към визуализацията.
Харесвам тази карта, защото за разлика от цветната, с която започнах, тя привлича повече вниманието към конкретни събития – като едно раждане в централна Африка или остров насред океана. В другата те са просто сурови цифри, които избледняват пред мащатите на други държави.
Любима ми е най-вече, защото в изготвянето ѝ ми се наложи да реша реален проблем като използвам няколко привидно несвързани източника на данни. Най-често, когато искаме да покажем ползата от отворените данни смесвайки различни източници (т.н. mashup), се получава малко насила. Не осъзнаваме колко достъпните източници на информация ни помагат в ежедневието – app-ове, карти, справки. Затова не разпознаваме тези примери като успешни mashup-и. Налага се да се илюстрира нещо нарочно с етикет opendata, за да има онзи „аха“ момент. Тук свързването се получи естествено и мисля, че резултатът е добър.
Може да разгледате картата на цяла страница в CartoDb.
В Github ще намерите кода и входните данни, с които я изготвих.


Опасността от отворените данни

Post Syndicated from Боян Юруков original http://feedproxy.google.com/~r/yurukov-blog/~3/qZ99oscegOE/


В този блог съм писал много за отворените данни – технологиите, ползите, конкретни проекти, напредъка в България и критика за липсата на такъв. Малко обаче се говори за опасността от отворените данни. Както многократно съм изтъквал, те са нищо повече от технологичен инструмент, а почти всеки инструмент може да се използва двояко. Те може да гарантират възможно най-голяма прозрачност, но дяволът винаги е в детайлите.
Тук ще срещнете някои от аргументите, които критиците на open data използват в старанието си да спрат реформите. С риск да им помогна с още такива, реших да събера всичко тук. Към всеки обаче съм добавил как може да се реши или защо значението му се преекспонира. Винаги ще има съпротива и неразбиране към нуждата за прозрачност и в никакъв случай едно решение не може да е перфектно. Още повече технологично решение като отворените данни. Важно е и да разберем какво значат те в сегашния контекст в България.
Риск за лични данни и корпоративна информация
Проблем
Това е едно от най-честите притеснения, когато се обсъжда темата за отворените данни. Когато се „отварят“ масиви от информация, част от тях може да съдържат лични данни или търговска информация. Ако не се внимава, чиновниците може да публикуват всичко и да създадат предпоставка за кражба на самоличност или смяна на собственост на фирма чрез измама.
Анализ
Такива коментари имаше след обсъждането на промяната на тарифата за достъп до базата данни на Търговския регистър. Тя обещава истинско отваряне на данните и възможност обикновени граждани и НПО-та да анализират информацията. В същото време обаче критиците на мярката изтъкват, че автоматичният анализ на данните ще позволи на т.н. „крадци на компании“ да идентифицират по-лесно потенциални жертви.
Има две важни точки, с които трябва да започнем. Първо, кражби на компании са се случвали доста преди публикуването на Търговския регистър. Второ, в описаната мярка не се дава достъп до повече информация, а само улеснява достъпа до вече съществуващ автоматичен интерфейс. В този смисъл потенциалните измамници няма да получат повече информация. Наистина, има вероятност да автоматизират търсенето си, но това е възможно и чрез платените сега системи за търговска информация. По-достъпните отворени данни до Търговския регистър обаче ще позволят на много други организации да следят и анализират за такива измами, което ще помогне за решаването и дори предотвратяването им.
В по-широкия смисъл, риск за личните данни съдържани в държавните информационни системи има и сега. Прилагането на принципа за отворени данни може да има само положителен ефект върху един съществуващ проблем. Всяка такава промяна изисква анализ кое може да е публично и кое не. Автоматизацията на отварянето на данни ще елиминира човешките грешки, като например забравена колона с лични адреси в Excel таблица.
Решение
Отварянето на обществени данни няма да създаде повече проблеми, но ще даде инструменти за решаването на съществуващите. Заради липсата на ясни процедури и протоколи за сигурност, досега сме ставали често свидетели на течове на лични данни. Проблемът тук не е в новата технология, а в начинът на работа до сега. Процесът на отваряне на данни може да промени това.
Друг метод за скриване на лична и служебна информация е агрегирането. Пример за това има в становището ми за новия Административен регистър, където предложих да се публикува сумата от натрупаните отпуски на служителите във всяко ведомство. При достатъчно добре избрано групиране се гарантира неприкосновеността на личността, но и че няма да има загуба на полезна публично достъпна информация.
Потенциална уязвимост в сигурността
Проблем
Тази опасност е вариация на предишната точка. Рискът е, че при автоматичните интерфейси, които предоставят възможност за справки в публична информация, може да има уязвимости. Тази възможност съществува и сега, но аргументът е, че при повече такива интерфейси, рискът за пропуски е по-голям.
Анализ
Пример за такъв пропуск е регистъра за позволенията за сеч на Агенцията по горите. Това е прекрасен пример за прозрачност въведен от последния служебен кабинет, макар и да не може да се квалифицира като отворени данни. Докато го разглеждах, забелязах определена уязвимост с базата данни. След сигнал до администраторите тя беше оправена.
Такива проблеми има винаги във всяка система и изчистването им е продължителен процес. Това обаче не може да бъде аргумент срещу автоматизирането на достъпа до обществена информация. Точно обратното – когато има хора, които се занимават точно с това и използват ресурсите активно, грешките се намират по-бързо. Това всъщност е дори аргумент в ползва на отворения код в администрацията.
Решение
За да се подобри сигурността, трябва повече прозрачност при създаването, тестването и поддържането на информационните системи. Подходът към сигурността на софтуерът сега е подобен на този на цялата администрация – крием всичко с надеждата, че никой няма да забележи дупките. Това очевидно далеч не е достатъчно с днешните технологии.
Манипулация на официалните данни
Проблем
Публикуваните справки може да бъдат манипулирани от съответните ведомства с цел прикриване на злоупотреби. Доверието в отворените данни и автоматизацията на анализа и визуализацията ще скрие тези манипулации.
Анализ
Подмяната на данни е сериозен проблем, който забелязваме и сега. Засичането ѝ е сравнително трудно, освен, ако не знаеш какво търсиш. Тук добър пример е системата за случайно разпределение на дела в съдебната система. Всички резултати от нея са публични, но отдавна се знае колко лесна за манипулиране е.
Решение
В света на отворените данни вече има решение на това и за него се изисква просто повече данни от различни източници. Автоматичната проверка ще покаже грешки в данните, но и проблеми в дефинициите и интерпретацията. Друго решение тук е автоматизирането на справките. При липсата на човешка намеса подмяната на публичните данни ще стане изключително трудна.
Манипулация на интерпретацията на данните
Проблем
Отворените данни са просто инструмент, но като такъв имат нужда от история или графика, която да изведе истинската им стойност. Основавайки се на реални данни, журналисти и НПО-та може да показват грешни интерпретации подменящи значението на информацията.
Анализ
Отново, този проблем съществува и сега. Виждаме го ясно с данните за раждаемостта. Когато псевдо-експерти, журналисти и политици искат да манипулират общественото мнение на база реални данни, то единствената надежда е отговор изтъкващ фактите. За това обаче няма нужда от реални данни – при липсата им първите винаги са си измисляли статистика.
Решение
Достъпа до повече публична информация би дал още инструменти за оборване на подобни подвеждащи изказвания. Не може да има технологично решение за липсата на етика при експерти и журналисти.
Технологична изолация на местния бизнес
Проблем
Това е опасност, която не е толкова очевидна. Информацията е сила, а отворените данни дават възможност за откриване на нови ниши и оптимизация на бизнеса. Големи корпорации със сериозен ресурс може да се възползват по-добре от публичната информация и стандартизирани egov услуги и да надделеят над местния бизнес с локалните му знания и опит.
Анализ
Този проблем може да се илюстрира със създаването и отварянето на кадастър в някои провинции на Индия. Силно фрагментираната и неформално дефинирана собственост на земята там е била пречка за големия бизнес и въпросния регистър е извадил от бизнеса много локални посредници. В България може да се направи подобен аналог с множеството фирми, които се изхранват с попълване на документи и изпълнение на конкретни задачи заради проблемите в администрацията. Друг пример у нас биха били обществените поръчки, ако и когато уведомяването и кандидатстването за тях станат изцяло електронни.
По-добрият и стандартизиран достъп до информация наистина може да помогне на компаниите с повече опит в анализа. Това е аргумент в привличането на чуждестранни инвестиции. Инструментите за анализ обаче са широко достъпни в наши дни и няма пречка за малките компании да ги използват. Точно обратното – това създава огромна технологична ниша на местно ниво. Далеч сме от универсален анализ и интеграция на данни, затова знанията и опита на местно ниво винаги ще бъде нужен. Нещо повече – малкият бизнес дори може да спечели за сметка на големите международни компании, защото ще има достъп до повече инструменти и анализи, които досега са стрували скъпи. Пример за това отново е отварянето на данните на Търговския регистър, постановлението за което все още престоява в Министерски съвет.
Улеснение за корпоративните лобисти
Проблем
Лобистки организации могат да използват същите тези инструменти за прозрачност, за да оптимизират отпорът си срещу регулаторни мерки.
Анализ
Отворените данни могат да се използват за идентифициране на проблеми в администрацията, изобличаване на корупция и проблеми при поръчки. Граждански организации могат да идентифицират рано проекти и наредби и да участват в дебатите. Аналогично обаче лобистките организации и НПО-та с непрозрачно финансиране могат да използват тези инструменти, за да оптимизират натиска си.
Пример за това може да бъдат проектите за закони и нормативни актове. Публикуването им на сайта на НС и Strategy.bg ни помага да реагираме по-рано, да задаваме правилните въпроси и да се организираме срещу корупционни практики и спорни текстове. Същото може да се направи обаче и срещу реформи заложени в тези проекти. Засичайки ги рано, тези организации може да организират кампании на дезинформация създавайки изкуствени скандали.
Решение
Отново този проблем съществува и сега. За жалост не малка част от медиите се използват като пощенски кутии за такива изкуствени скандали. Лобистки поправки и влияние се забелязват отдавана и каналите, по които получават информация за подготвени проекти, далеч не се ограничава до публично публикуваната информация. Отворените данни биха били решение именно на този проблем, защото биха автоматизирали публичността на редица процеси. Пример затова е случайното разпределение на делата, публичните консултации и обществените поръчки.
Обръщането на същия този механизъм срещу прозрачността и в полза на лобиските практики е теоретична възможност. Това само по себе си обаче няма да остане скрито, което до голяма степен ще го обезсмисли. Негативните кампании в медиите съществуват и сега и няма да се преборим с тях чрез повече публичност. Те са въпрос на медийна етика и обществено съзнание – въпроси, които не могат да се решат с технологии.