POI classification system is bad and we need it be redesigned.
Use case: I wanna buy specific chemical. I wanna find companies nearby selling the chemical I need. I don’t want to find all the companies selling all the chemicals, I need only to find the ones selling the chemical I need.
Problem: Today we can’t target POI’s by exact good or service they provide.
The solution is to throw away old classification framework and write the new one of the following design.
1 We should not use key-value pairs. Instead we should use JSON documents. We map old fields names to a new JSON paths in the obvious way:
.........
"addr:street"="Purple"
"addr:housenumber"=13
will be converted to
{
.........,
"addr" : {
"street" : "Purple",
"housenumber" : 13,
.........
}
}
2 All metadata are stored in a DB. My proposal assumes MongoDB (since it operates JSON (in fact BSON, but noone cares)), but it can be reingeneered to any other DB.
3 Types: there are standard JSON data types alongside with enum data type. Enum data type is an unique integer ID referring to a record with that ID.
4 Classifications should have enum data type.
5 We introduce a database of goods and services. It is hierarchical. It is a tree of objects. Every node of this tree must have “_id” property which will be used as enum id.
The example is
{
"good" : {
"_id":1,
"chemical" : {
"_id":1337,
...,
"isopropyl alcohol" : {
"_id" : 1234,
"CAS" : "67-63-0",
"IUPAC" : "Propan-2-ol",
"pure substance" : true,
...
},
...,
},
"food" : {...},
"device" : {...},
...
},
"service" : {
"_id":2,
"accomodation" : {...},
"healthcare" : {...},
"technology" : {
"_id":3,
"manufacturing" : {
"_id":4,
"cutting" : {
"laser" : {...},
"hydro" : {...},
"plasma" : {...},
"grinder" : {...}
},
"positive manufacturing" : {
...,
"3d printing" : {...}
}
},
"repairing and installation" : {
"devices" {
...,
"electronic" : {
...,
"TV" : {...},
"PC" : {...}
},
"mechanic" : {
"transport" : {
"car" : {...},
....
},
"refrigerators" : {...},
...
}
}
}
},
"recreational" : {
"show" : {
"sport" : {...},
"theatre" : {...},
"exibition" : {
"gallery" : {
"picture" : {...}
},
...
}
},
"activity" : {
"physical" : {...},
...
},
...
},
"legal advice" : {
...
},
"insurance" : {
"movable" : {
"transport" : {
"car" : {...},
...
},
},
"immovable" : {
...
},
"personal" : {
"life" : {
...
}
...
}
},
"criminal&government" : {
"force" : {
"torture" : {
"beating" : {...},
...
},
"killing" : {...},
"kidnapping" : {...},
"extortion" : {...},
"robbery" : {...},
"espionage" : {...},
"war" : {...},
...
},
"bribery" {...},
},
...
}
...
}
This was a JSON representation of database structure, actual way of mapping this structure to DB structures depends on chosen stack of technologies. For example it can be a table in an SQL db (for example PostgreSQL), each row represents each object, the fields are ID (primary key), list of parents and a JSON with rest of fields.
6 We throw away these “amenity”, “shop”, “office”, and other similar fields (I call them “amenity-like”) and introduce a new field “product”. It contains an mapping of ids for goods and services provided by an org to additional info.
The example is
{
.........,
"product" : {
"1234" : {
"assay" : 0.9
},
}
}
It means that the org sells a product with id 1234 (isopropyl alcohol) and its assay is 0.9.
7 Software should map hierarchical paths typed in GUI to IDs and show tooltips. IDs should be used by software internally.
8 Disadvantages: it is not compatible with old osm software. But JSON parsers are widespread, so it will be no much problem.