[OSM-dev] GSoC: formalising knowledge in OSM
Dear Openstreetmap community, My name is Radomir Cernoch and as a long-time OSM user, I have recently started creating maps. I must say I was quite surprised, how difficult it is to start producing maps in a proper way and good quality -- the possibilities and complexness of OSM is quite high. Since I am a student (doing AI, knowledge engineering specialism) I thought about the currently running GSoC 2009, in which OSM takes part. My idea, which I am proposing, is to build a taxonomy of map elements formalised in an ontology, which could formally define and classify them. I believe that such project could build a well-structured knowledge base aiding beginners to understand nitty-gritties of mapping, yet still useable for skilled users. Its main long-term benefit would then be providing a single place to store all knowledge about map elements, which could be used across whole OSM project (JOSM, maplint, rendering and web front-end). This can unify the data duplicated between eg. JOSM menus and wiki documentation. I am not sure how familiar are you with knowledge engineering, so I thought I would propose some areas, where such technology could be useful and let you ask about anything you might want to. Currently I can think of exploiting this idea in following areas: - Creating an automatic and coherent documentation for wiki. An ontology includes a clearly defined taxonomy and annotations, which can be easily converted into a well arranged web page. - Integration into JOSM could provide a more user-friendly GUI: Currenty the presets menu allow you to assign predefined key-value pairs to a node or path, but there is no way how to edit existing key-value pairs of existing element (apart from editing them by hand). An ontology could provide a clean way to determine which real-world element corresponds to current node and provide appropriate options. - Handle region specific delicacies. Eg. In Czech Republic we have a very specific tourist signs. In the proposed system such knowledge could be easily incorporated, but become filtered out for different countries. Then there are some other areas, where it could be benefitial (but I have not gone into these ideas very deep): - Assisting in building an search engine for structured queries. Eg. google maps provides a great search engine for unstructured queries like Bus station in Prague. The advantage of OSM can be to pose precise questions like bus station in Prague which has wheel-chair access. With an ontology, translation of such questions into SQL should be easy. - Ontologies are a big topic in semantic web and they could potentially help OSM in this field. - As the ontology represents general, high-level ideas, it should not suffer from API changes. As far as the GSoC is concerned, I was thinking about including the following bits: Firstly create the initial ontology to support at least all official map elements. Possibly, there could be an API to it, which would encapsulate common operations and reasoning to provide an easy integration into standard programming languages. Lastly an export to wiki (or even import?) utility would be created in order to expose and promote this technology to users and developers. I am happy to hear any comments and criticism from you (especially from people who offered to supervise GSoC students this year). Yours sincerely, Radomir Cernoch ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Google Summer of Code
2009/3/25 Iván Sánchez Ortega i...@sanchezortega.es: El Miércoles, 25 de Marzo de 2009, José Ricardo escribió: My interests are converging into the area of ubiquitous computing in which localization plays a significant role (navigation, context awareness, ...) as well as mobile development, Of course, I would like to hear the community's take on the idea Can you tell us what do you want to do, without so many buzzwords? Saying an app to edit OSM data on-the-fly for the Android platform or something like that would be much clearer than the above phrase :-) :-) Remember that this is the dev list, we're (mostly) coders here, and GSoC is a coding project. As Iván says, we need more technical details about what you intend to work on! Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC: formalising knowledge in OSM
On Mar 25, 2009, at 10:36, Radomír Černoch wrote: Since I am a student (doing AI, knowledge engineering specialism) I thought about the currently running GSoC 2009, in which OSM takes part. My idea, which I am proposing, is to build a taxonomy of map elements formalised in an ontology, which could formally define and classify them. I believe that such project could build a well-structured knowledge base aiding beginners to understand nitty-gritties of mapping, yet still useable for skilled users. I don't have an opinion on whether this would be a good GSOC project, but here's some relevant wiki pages: http://wiki.openstreetmap.org/wiki/Machine-readable_Map_Feature_list http://wiki.openstreetmap.org/wiki/Machine-readable_Map_Feature_list/OWL_Semantic_Wiki_and_more http://wiki.openstreetmap.org/wiki/User:Ck3d/Ontology_Proposal http://wiki.openstreetmap.org/wiki/Semantic_MediaWiki Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC: formalising knowledge in OSM
2009/3/25 Radomír Černoch radomir.cern...@gmail.com: Firstly create the initial ontology to support at least all official map elements. Hi Radomír, There's no such thing. In fact, the lack of a fixed/official ontology is held as one of the key defining attributes of the success, flexibility and scalability of OSM, so I'm not sure how well your project will work in the long run. I could see you getting to the end of your project and having a working system that is used here and there, but isn't accepted by significant parts of the OSM community. Some other project where a successful outcome to your summer leads to wider acceptance of your code is probably a better idea. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Google Summer of Code
On Wed, Mar 25, 2009 at 10:59 AM, Andy Allan gravityst...@gmail.com wrote: 2009/3/25 Iván Sánchez Ortega i...@sanchezortega.es: El Miércoles, 25 de Marzo de 2009, José Ricardo escribió: My interests are converging into the area of ubiquitous computing in which localization plays a significant role (navigation, context awareness, ...) as well as mobile development, Of course, I would like to hear the community's take on the idea Can you tell us what do you want to do, without so many buzzwords? Saying an app to edit OSM data on-the-fly for the Android platform or something like that would be much clearer than the above phrase :-) :-) Remember that this is the dev list, we're (mostly) coders here, and GSoC is a coding project. As Iván says, we need more technical details about what you intend to work on! or even better - improve editing support in andnav for ways/relations* :-) cheers, matt *: i think they already have POI editing support. but if not, then that too. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC: formalising knowledge in OSM
2009/3/25 Radomír Černoch radomir.cern...@gmail.com: Firstly create the initial ontology to support at least all official map elements. Hi Radomír, There's no such thing. In fact, the lack of a fixed/official ontology is held as one of the key defining attributes of the success, flexibility and scalability of OSM, so I'm not sure how well your project will work in the long run. I could see you getting to the end of your project and having a working system that is used here and there, but isn't accepted by significant parts of the OSM community. Some other project where a successful outcome to your summer leads to wider acceptance of your code is probably a better idea. I wouldn't say so. He is not suggesting to restrict people from putting things into the database, but to build a machine-readable description of what is actually in there. Simply replace official by commonly used, and his ideas make a lot of sense. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Google Summer of Code
On Wed, Mar 25, 2009 at 11:18 AM, Matt Amos zerebub...@gmail.com wrote: or even better - improve editing support in andnav for ways/relations* :-) /me FAIL. andnav isn't open-source, although parts of it might be re-used. cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Google Summer of Code
Matt Amos wrote: On Wed, Mar 25, 2009 at 11:18 AM, Matt Amos zerebub...@gmail.com wrote: or even better - improve editing support in andnav for ways/relations* :-) /me FAIL. andnav isn't open-source In opposition to Vespucci. My interests are converging into the area of ubiquitous computing in which localization plays a significant role (navigation, context awareness, ...) as well as mobile development, so I was thinking of applying for the Android Navigation Application. The android platform is one full of capacities so I was thinking the application developed could even be extended to allow the whole process of logging GPS traces, editing/tagging, uploading and navigating. Of course, I would like to hear the community's take on the idea and understand the importance/impact of such app for the Open Street Map project. You're welcome to join our group! We're developing Vespucci, an on-the-fly editor for OpenStreetMap on Android! http://code.google.com/p/osmeditor4android/ If you need further information, don't hesitate to ask or better: Join our mailinglist: http://groups.google.com/group/osmeditor4android Regards, Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Better History
2009/3/25 Frederik Ramm frede...@remote.org Hi, Igor Shubovych wrote: This demands completely changing of the OSM API. I only think if it is good idea to change the whole protocol just to make history more clear. No, I wasn't suggesting any API change. I said: Ideally of course, the API would support such complex operations (so you could call an API function split way and it would be recorded in history as such). But this is not going to happen any time soon. and then suggested that we could make the client upload detailed information about what it did. For example, if you have way 1 consisting of nodes a,b,c and way 2 consisting of nodes c,d,e. User now combines both in the editor. Editor would normally delete way 2 and add nodes d,e to way 1. Someone who later calls up the history of way 2 thinks: What the hell, that was an important road, why was it deleted? If the editor would, before it deletes way 2, upload a new version of way 2 with a tag note=this way is now going to be deleted because it is merged with way 1, and only delete way 2 after that, then someone who later looks at the history of way 2 sees what happened. All without API changes. Aha, I see. May be great idea. But the problem will be when you try to store all history in the fields. It is ok when it is history=merged with N#12345 However this looks strange after some more time: history=added N#12345,split to W#123456 W#1234567, merged with W#22, added to R#10 Regards, Igor Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Google Summer of Code
On Wed, Mar 25, 2009 at 11:46 AM, Matthias Brandt mattelacchiato.l...@googlemail.com wrote: Matt Amos wrote: /me FAIL. andnav isn't open-source In opposition to Vespucci. i'd been looking for that editing screenshot you have of the large edit areas - i couldn't find it and assumed it must have been an andnav screenshot. i've put a page on the OSM wiki linking to your google code project so i don't forget again! looks like an excellent candidate for some help with the 0.6 API change? cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Google Summer of Code
Matt Amos wrote: i'd been looking for that editing screenshot you have of the large edit areas - i couldn't find it and assumed it must have been an andnav screenshot. i've put a page on the OSM wiki linking to your google code project so i don't forget again! Oh, thanks! looks like an excellent candidate for some help with the 0.6 API change? Yes, Vespucci has to be updated for API 0.6! Are you interested? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] [PATCH] Allow line drawing for local GPX files only
The attached patch modifies the options for GPX line drawing to allow
lines to be drawn only for files loaded from a local drive, and not for
layers downloaded from the OSM server. Per-layer/file preferences still
override this behaviour.
--
Jonathan (Jonobennett)
# This patch file was generated by NetBeans IDE
# Following Index: paths are relative to: Z:\Projects\JOSM\src
# This patch can be applied using context Tools: Patch action on respective
folder.
# It uses platform neutral UTF-8 encoding and \n newlines.
# Above lines and this line are ignored by the patching process.
Index: org/openstreetmap/josm/actions/OpenFileAction.java
--- org/openstreetmap/josm/actions/OpenFileAction.java Base (BASE)
+++ org/openstreetmap/josm/actions/OpenFileAction.java Locally Modified (Based
On LOCAL)
@@ -116,7 +116,7 @@
}
r = new GpxReader(is,file.getAbsoluteFile().getParentFile());
r.data.storageFile = file;
-GpxLayer gpxLayer = new GpxLayer(r.data, fn);
+GpxLayer gpxLayer = new GpxLayer(r.data, fn, true);
Main.main.addLayer(gpxLayer);
if (Main.pref.getBoolean(marker.makeautomarkers, true)) {
MarkerLayer ml = new MarkerLayer(r.data, tr(Markers from
{0}, fn), file, gpxLayer);
@@ -154,7 +154,7 @@
NmeaReader r = new NmeaReader(new FileInputStream(file),
file.getAbsoluteFile().getParentFile());
if(r.getNumberOfCoordinates()0) {
r.data.storageFile = file;
-GpxLayer gpxLayer = new GpxLayer(r.data, fn);
+GpxLayer gpxLayer = new GpxLayer(r.data, fn, true);
Main.main.addLayer(gpxLayer);
if (Main.pref.getBoolean(marker.makeautomarkers, true)) {
MarkerLayer ml = new MarkerLayer(r.data, tr(Markers from
{0}, fn), file, gpxLayer);
Index: org/openstreetmap/josm/gui/layer/GpxLayer.java
--- org/openstreetmap/josm/gui/layer/GpxLayer.java Base (BASE)
+++ org/openstreetmap/josm/gui/layer/GpxLayer.java Locally Modified (Based On
LOCAL)
@@ -82,6 +82,7 @@
private Color computeCacheColorUsed;
private colorModes computeCacheColored;
private int computeCacheColorTracksTune;
+ private boolean isLocalFile;
public GpxLayer(GpxData d) {
super((String) d.attr.get(name));
@@ -95,6 +96,12 @@
this.name = name;
}
+ public GpxLayer(GpxData d, String name, boolean isLocal) {
+ this(d);
+ this.name = name;
+ this.isLocalFile = isLocal;
+ }
+
@Override public Icon getIcon() {
return ImageProvider.get(layer, gpx_small);
}
@@ -389,7 +396,7 @@
// don't draw lines if longer than x meters
int maxLineLength =
Main.pref.getInteger(draw.rawgps.max-line-length, -1);
// draw line between points, global setting
-boolean lines = Main.pref.getBoolean(draw.rawgps.lines);
+boolean lines = (Main.pref.getBoolean(draw.rawgps.lines) ||
(Main.pref.getBoolean(draw.rawgps.lines.localfiles) this.isLocalFile));
String linesKey = draw.rawgps.lines.layer +name;
// draw lines, per-layer setting
if (Main.pref.hasKey(linesKey))
Index: org/openstreetmap/josm/gui/preferences/DrawingPreference.java
--- org/openstreetmap/josm/gui/preferences/DrawingPreference.java Base (BASE)
+++ org/openstreetmap/josm/gui/preferences/DrawingPreference.java Locally
Modified (Based On LOCAL)
@@ -26,7 +26,11 @@
public class DrawingPreference implements PreferenceSetting {
-private JCheckBox drawRawGpsLines = new JCheckBox(tr(Draw lines between
raw gps points.));
+private ButtonGroup gpsLinesGroup;
+ private JRadioButton drawRawGpsLinesAll = new JRadioButton(tr(All));
+private JRadioButton drawRawGpsLinesLocal = new JRadioButton(tr(Local
files));
+ private JRadioButton drawRawGpsLinesNone = new JRadioButton(tr(None));
+ private ActionListener drawRawGpsLinesActionListener;
private JTextField drawRawGpsMaxLineLength = new JTextField(8);
private JCheckBox forceRawGpsLines = new JCheckBox(tr(Force lines if no
segments imported.));
private JCheckBox largeGpsPoints = new JCheckBox(tr(Draw large GPS
points.));
@@ -53,30 +57,49 @@
panel.setBorder(BorderFactory.createEmptyBorder(5,5,5,5));
// drawRawGpsLines
-drawRawGpsLines.addActionListener(new ActionListener(){
+ gpsLinesGroup = new ButtonGroup();
+ gpsLinesGroup.add(drawRawGpsLinesNone);
+ gpsLinesGroup.add(drawRawGpsLinesLocal);
+ gpsLinesGroup.add(drawRawGpsLinesAll);
+
+ if(Main.pref.getBoolean(draw.rawgps.lines)) {
+ drawRawGpsLinesAll.setSelected(true);
+ } else if
(Main.pref.getBoolean(draw.rawgps.lines.localfiles)) {
+ drawRawGpsLinesLocal.setSelected(true);
+ } else {
+
Re: [OSM-dev] Google Summer of Code
On Wed, Mar 25, 2009 at 12:43 PM, Matthias Brandt mattelacchiato.l...@googlemail.com wrote: Matt Amos wrote: looks like an excellent candidate for some help with the 0.6 API change? Yes, Vespucci has to be updated for API 0.6! Are you interested? yes, i'll definitely take a look at it. cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
The amount of 'potlatch' in the attached document is in my opinion again a bit too high. This ran on the planet export of yesterday. So I'll check it in today. I'll also run the 'hey, go away, empty way'-script but those are still to be detected. Stefan ++--+-+---+ | L6 | way | k | v | ++==+=+===+ | 2 | 21337772 | tiger:county| Willacy, TX | | 2 | 21337772 | tiger:tlid | 88260494:88260591:88260573:88 | :: : : 260684:88260654:88260632:8826 : :: : : 0762:88260771:88260780:882607 : :: : : 83:88261573:88261575:88260790 : :: : : :88260786:88260775:88260764:8 : :: : : 8260751:88260738:88260703:882 : :: : : 60541 : | 2 | 21337772 | highway | residential | | 2 | 21337772 | tiger:upload_uuid | bulk_upload.pl-2dbd3cb9-b6cf- | :: : : 46de-8e09-117071f1d52f: | 2 | 21337772 | tiger:reviewed | no| | 2 | 21337772 | tiger:source| tiger_import_dch_v0.6_2007083 | :: : : 0 : | 2 | 21337772 | tiger:zip_right | 78580 | | 2 | 21337772 | tiger:cfcc | A41 | | 2 | 21337772 | tiger:separated | no| | 2 | 21337925 | tiger:county| Willacy, TX | | 2 | 21337925 | tiger:source| tiger_import_dch_v0.6_2007083 | :: : : 0 : | 2 | 21337925 | created_by | Potlatch 0.10f| | 2 | 21337925 | tiger:name_direction_suffix | W | | 2 | 21337925 | name| Farm-to-Market Road 1762 W | | 2 | 21337925 | tiger:name_base | Farm-to-Market Road 1762 | | 2 | 21337925 | highway | residential | | 2 | 21337925 | tiger:name_base_1 | Farm-to-Market Road 1762 | | 2 | 21337925 | tiger:separated | no| | 2 | 21337925 | tiger:tlid | 88265652:88260201:88261418:88 | :: : : 268565:88268566:88260197:8826 : :: : : 0199:88261320:88261329: | 2 | 21337925 | tiger:reviewed | no| | 2 | 21337925 | name_1 | Farm-to-Market Road 1762 | | 2 | 21337925 | tiger:upload_uuid | bulk_upload.pl-2dbd3cb9-b6cf- | :: : : 46de-8e09-117071f1d52f: | 2 | 21337925 | tiger:cfcc | A41 | | 2 | 28010851 | name| Stanley Bank Way | | 2 | 28010851 | created_by | Potlatch 0.10f| | 2 | 28010851 | highway | trunk | | 2 | 28010851 | ref | A58 | | 2 | 31878573 | name| ש×ר×ת ×× ××ר××× | | 2 | 31878573 | created_by | Potlatch 0.10f| | 2 | 31878573 | name:he | ש×ר×ת ×× ××ר××× | | 2 | 31878573 | highway | tertiary | | 2 | 31878573 | name:en | Ben Gurion Avenue | | 2 | 31878573 | oneway | yes | | 2 | 32213215 | name| Carrera 6 | | 2 | 32213215 | created_by | Potlatch 0.10f| | 2 | 32213215 | highway | secondary | ++--+-+---+ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
Stefan de Konink wrote: The amount of 'potlatch' in the attached document As has been explained to you, you mean the amount of API ;) http://lists.openstreetmap.org/pipermail/dev/2009-January/013768.html cheers Richard -- View this message in context: http://www.nabble.com/OSM-Fixer-tp22636487p22702504.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
Richard Fairhurst wrote: Stefan de Konink wrote: The amount of 'potlatch' in the attached document As has been explained to you, you mean the amount of API ;) Yeah yeah... I knew this would trigger you to a response; My next mail includes the b0rk3d ways and relations. I can already tell you ~2. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
Stefan de Konink wrote: I'll also run the 'hey, go away, empty way'-script but those are still to be detected. http://kinkrsoftware.nl/contrib/osm/brokenways.txt.gz The 'hey borked relation'-script output: http://kinkrsoftware.nl/contrib/osm/brokenrelations.txt.gz I'll download the ways first and see if the way is empty if all brokenness is removed, if so it will be deleted. If not only the node that doesn't exist anymore will be deleted. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
2009/3/25 Stefan de Konink ste...@konink.de: Richard Fairhurst wrote: Stefan de Konink wrote: The amount of 'potlatch' in the attached document As has been explained to you, you mean the amount of API ;) Yeah yeah... I knew this would trigger you to a response; My next mail includes the b0rk3d ways and relations. I can already tell you ~2. and the purpose of filling our mail boxes with these lists is what exactly? It's a known problem with a fix on the way with 0.6. Repairing the damage is helpful. Moaning about it with added unhelpful and ignorant opinions isn't. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
Dave Stubbs wrote: 2009/3/25 Stefan de Konink ste...@konink.de: Richard Fairhurst wrote: Stefan de Konink wrote: The amount of 'potlatch' in the attached document As has been explained to you, you mean the amount of API ;) Yeah yeah... I knew this would trigger you to a response; My next mail includes the b0rk3d ways and relations. I can already tell you ~2. and the purpose of filling our mail boxes with these lists is what exactly? Maybe someone wants to peak at when and with what this occurs? It's a known problem with a fix on the way with 0.6. Is this already checked that it will be fixed using 0.6? Since currently the API doesn't seem to be the problem, the lacking referential constraints inside the database, and resulting database export is. Repairing the damage is helpful. Moaning about it with added unhelpful and ignorant opinions isn't. Then please tell me; I just provided to everyone who was interested the exact broken relations. Could you check directly in the main MySQL installation if these relations are present or not? Or that this is an hypercube issue? Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
On Wed, Mar 25, 2009 at 3:07 PM, Stefan de Konink ste...@konink.de wrote: It's a known problem with a fix on the way with 0.6. Is this already checked that it will be fixed using 0.6? Since currently the API doesn't seem to be the problem, the lacking referential constraints inside the database, and resulting database export is. Not sure if you're just being obtuse or you really don't know what we're talking about, but when we say API 0.6 we mean new version of the XML API + new version of the Rails code + new version of db structure (yes, including foreign keys etc) that all go hand in hand. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC: formalising knowledge in OSM
Hi Radomír four months ago we saw a similar discussion on this list. It lead to a proposal for a machine-readable map-feature list [1] and to a proposal for managing map features using Semantic MediaWiki, see the wiki prototype[2]. There is also an article on the OSM wiki which tries to explain how the Web Ontology Language, Semantic Mediawiki and OSM map features are related[3]. Unfortunatelly, we didn't make any progress in the last two months. I'd still be interested in a well-managed machine-readable map feature list and I encourage you to pursue your ideas. Regards Karl [1] http://wiki.openstreetmap.org/wiki/Machine-readable_Map_Feature_list [2] http://dev.openstreetmap.org/~edgemaster/semwiki/index.php/Main_Page [3] http://wiki.openstreetmap.org/wiki/Machine-readable_Map_Feature_list/OWL_Sem antic_Wiki_and_more -Ursprüngliche Nachricht- Von: dev-boun...@openstreetmap.org [mailto:dev-boun...@openstreetmap.org] Im Auftrag von Radomír Cernoch Gesendet: Mittwoch, 25. März 2009 10:36 An: dev@openstreetmap.org Betreff: [OSM-dev] GSoC: formalising knowledge in OSM Dear Openstreetmap community, My name is Radomir Cernoch and as a long-time OSM user, I have recently started creating maps. I must say I was quite surprised, how difficult it is to start producing maps in a proper way and good quality -- the possibilities and complexness of OSM is quite high. Since I am a student (doing AI, knowledge engineering specialism) I thought about the currently running GSoC 2009, in which OSM takes part. My idea, which I am proposing, is to build a taxonomy of map elements formalised in an ontology, which could formally define and classify them. I believe that such project could build a well-structured knowledge base aiding beginners to understand nitty-gritties of mapping, yet still useable for skilled users. Its main long-term benefit would then be providing a single place to store all knowledge about map elements, which could be used across whole OSM project (JOSM, maplint, rendering and web front-end). This can unify the data duplicated between eg. JOSM menus and wiki documentation. I am not sure how familiar are you with knowledge engineering, so I thought I would propose some areas, where such technology could be useful and let you ask about anything you might want to. Currently I can think of exploiting this idea in following areas: - Creating an automatic and coherent documentation for wiki. An ontology includes a clearly defined taxonomy and annotations, which can be easily converted into a well arranged web page. - Integration into JOSM could provide a more user-friendly GUI: Currenty the presets menu allow you to assign predefined key-value pairs to a node or path, but there is no way how to edit existing key-value pairs of existing element (apart from editing them by hand). An ontology could provide a clean way to determine which real-world element corresponds to current node and provide appropriate options. - Handle region specific delicacies. Eg. In Czech Republic we have a very specific tourist signs. In the proposed system such knowledge could be easily incorporated, but become filtered out for different countries. Then there are some other areas, where it could be benefitial (but I have not gone into these ideas very deep): - Assisting in building an search engine for structured queries. Eg. google maps provides a great search engine for unstructured queries like Bus station in Prague. The advantage of OSM can be to pose precise questions like bus station in Prague which has wheel-chair access. With an ontology, translation of such questions into SQL should be easy. - Ontologies are a big topic in semantic web and they could potentially help OSM in this field. - As the ontology represents general, high-level ideas, it should not suffer from API changes. As far as the GSoC is concerned, I was thinking about including the following bits: Firstly create the initial ontology to support at least all official map elements. Possibly, there could be an API to it, which would encapsulate common operations and reasoning to provide an easy integration into standard programming languages. Lastly an export to wiki (or even import?) utility would be created in order to expose and promote this technology to users and developers. I am happy to hear any comments and criticism from you (especially from people who offered to supervise GSoC students this year). Yours sincerely, Radomir Cernoch ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC: formalising knowledge in OSM
Unfortunatelly, we didn't make any progress in the last two months. I'd still be interested in a well-managed machine-readable map feature list and I encourage you to pursue your ideas. The progress stopped because the current Wiki Server can't handle the Semantic MediaWiki extension in a large scale. I hope this approach will go on as soon as we get a new server. Regards Joerg ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] style TIGER
I've made a slight change to my style file so that ways which have tiger:reviewed are rendered specially. It's important that people review the TIGER data because it's not so reliable. I'd like to get this into JOSM. Should I just submit a patch? -- --my blog is athttp://blog.russnelson.com Cloudmade supports http://openstreetmap.org/ 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] OSM Fixer [Sequal]
Andy Allan wrote: On Wed, Mar 25, 2009 at 3:07 PM, Stefan de Konink ste...@konink.de wrote: It's a known problem with a fix on the way with 0.6. Is this already checked that it will be fixed using 0.6? Since currently the API doesn't seem to be the problem, the lacking referential constraints inside the database, and resulting database export is. Not sure if you're just being obtuse or you really don't know what we're talking about, but when we say API 0.6 we mean new version of the XML API + new version of the Rails code + new version of db structure (yes, including foreign keys etc) that all go hand in hand. http://wiki.openstreetmap.org/wiki/0.6#Related_database_improvements I cannot get from that page that you are adding these things, only adding object, key unique; (the debate that this is not smart and should be object,key,value is outside the scope of the discussion now, if presented that way it can be a serious improvement to allocate a table per key, no i am not joking) Never the less, I asked Dave if he checked in the MySQL database if the presented violators are in there or if this is a hypercube issue. I would like to have a reply to that, because then it might be an issue that should be addressed by more people. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
On Wed, Mar 25, 2009 at 4:47 PM, Stefan de Konink ste...@konink.de wrote: Andy Allan wrote: On Wed, Mar 25, 2009 at 3:07 PM, Stefan de Konink ste...@konink.de wrote: It's a known problem with a fix on the way with 0.6. Is this already checked that it will be fixed using 0.6? Since currently the API doesn't seem to be the problem, the lacking referential constraints inside the database, and resulting database export is. Not sure if you're just being obtuse or you really don't know what we're talking about, but when we say API 0.6 we mean new version of the XML API + new version of the Rails code + new version of db structure (yes, including foreign keys etc) that all go hand in hand. http://wiki.openstreetmap.org/wiki/0.6#Related_database_improvements I cannot get from that page that you are adding these things yeah, the wiki page could probably do with some updating. but you remember this thread last month, right? http://lists.openstreetmap.org/pipermail/dev/2009-February/014024.html the issue with things referencing deleted items should go away because the transactions wrap the used-by checks. Never the less, I asked Dave if he checked in the MySQL database if the presented violators are in there or if this is a hypercube issue. I would like to have a reply to that, because then it might be an issue that should be addressed by more people. looks like it might be a planet generation issue. maybe take a look at the history for some of the items which are causing you problems? cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
Matt Amos wrote: yeah, the wiki page could probably do with some updating. but you remember this thread last month, right? http://lists.openstreetmap.org/pipermail/dev/2009-February/014024.html the issue with things referencing deleted items should go away because the transactions wrap the used-by checks. True; But isn't Rails doing that now too? [I am talking about the main database] Never the less, I asked Dave if he checked in the MySQL database if the presented violators are in there or if this is a hypercube issue. I would like to have a reply to that, because then it might be an issue that should be addressed by more people. looks like it might be a planet generation issue. maybe take a look at the history for some of the items which are causing you problems? That is exactly the reason I want to know if it is currently in the main database or not. http://api.openstreetmap.org/api/0.5/way/4043588/history http://api.openstreetmap.org/api/0.5/node/292984561/history The issue is that the hypercube 'dump' contains the waynds on 4043588, 292984561. Grant, Tom, could any of you if specifically this relation still exist in the main database? Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] [PATCH] Allow line drawing for local GPX files only
Why isn't the current method suitable? All downloaded layers have the
same name and therefore are normally customizable without additional
effort.
Greetings
xeen
2009/3/25 Jonathan Bennett openstreet...@jonno.cix.co.uk:
The attached patch modifies the options for GPX line drawing to allow
lines to be drawn only for files loaded from a local drive, and not for
layers downloaded from the OSM server. Per-layer/file preferences still
override this behaviour.
--
Jonathan (Jonobennett)
# This patch file was generated by NetBeans IDE
# Following Index: paths are relative to: Z:\Projects\JOSM\src
# This patch can be applied using context Tools: Patch action on respective
folder.
# It uses platform neutral UTF-8 encoding and \n newlines.
# Above lines and this line are ignored by the patching process.
Index: org/openstreetmap/josm/actions/OpenFileAction.java
--- org/openstreetmap/josm/actions/OpenFileAction.java Base (BASE)
+++ org/openstreetmap/josm/actions/OpenFileAction.java Locally Modified
(Based On LOCAL)
@@ -116,7 +116,7 @@
}
r = new GpxReader(is,file.getAbsoluteFile().getParentFile());
r.data.storageFile = file;
- GpxLayer gpxLayer = new GpxLayer(r.data, fn);
+ GpxLayer gpxLayer = new GpxLayer(r.data, fn, true);
Main.main.addLayer(gpxLayer);
if (Main.pref.getBoolean(marker.makeautomarkers, true)) {
MarkerLayer ml = new MarkerLayer(r.data, tr(Markers from
{0}, fn), file, gpxLayer);
@@ -154,7 +154,7 @@
NmeaReader r = new NmeaReader(new FileInputStream(file),
file.getAbsoluteFile().getParentFile());
if(r.getNumberOfCoordinates()0) {
r.data.storageFile = file;
- GpxLayer gpxLayer = new GpxLayer(r.data, fn);
+ GpxLayer gpxLayer = new GpxLayer(r.data, fn, true);
Main.main.addLayer(gpxLayer);
if (Main.pref.getBoolean(marker.makeautomarkers, true)) {
MarkerLayer ml = new MarkerLayer(r.data, tr(Markers from
{0}, fn), file, gpxLayer);
Index: org/openstreetmap/josm/gui/layer/GpxLayer.java
--- org/openstreetmap/josm/gui/layer/GpxLayer.java Base (BASE)
+++ org/openstreetmap/josm/gui/layer/GpxLayer.java Locally Modified (Based On
LOCAL)
@@ -82,6 +82,7 @@
private Color computeCacheColorUsed;
private colorModes computeCacheColored;
private int computeCacheColorTracksTune;
+ private boolean isLocalFile;
public GpxLayer(GpxData d) {
super((String) d.attr.get(name));
@@ -95,6 +96,12 @@
this.name = name;
}
+ public GpxLayer(GpxData d, String name, boolean isLocal) {
+ this(d);
+ this.name = name;
+ this.isLocalFile = isLocal;
+ }
+
@Override public Icon getIcon() {
return ImageProvider.get(layer, gpx_small);
}
@@ -389,7 +396,7 @@
// don't draw lines if longer than x meters
int maxLineLength =
Main.pref.getInteger(draw.rawgps.max-line-length, -1);
// draw line between points, global setting
- boolean lines = Main.pref.getBoolean(draw.rawgps.lines);
+ boolean lines = (Main.pref.getBoolean(draw.rawgps.lines) ||
(Main.pref.getBoolean(draw.rawgps.lines.localfiles) this.isLocalFile));
String linesKey = draw.rawgps.lines.layer +name;
// draw lines, per-layer setting
if (Main.pref.hasKey(linesKey))
Index: org/openstreetmap/josm/gui/preferences/DrawingPreference.java
--- org/openstreetmap/josm/gui/preferences/DrawingPreference.java Base (BASE)
+++ org/openstreetmap/josm/gui/preferences/DrawingPreference.java Locally
Modified (Based On LOCAL)
@@ -26,7 +26,11 @@
public class DrawingPreference implements PreferenceSetting {
- private JCheckBox drawRawGpsLines = new JCheckBox(tr(Draw lines between
raw gps points.));
+ private ButtonGroup gpsLinesGroup;
+ private JRadioButton drawRawGpsLinesAll = new JRadioButton(tr(All));
+ private JRadioButton drawRawGpsLinesLocal = new JRadioButton(tr(Local
files));
+ private JRadioButton drawRawGpsLinesNone = new
JRadioButton(tr(None));
+ private ActionListener drawRawGpsLinesActionListener;
private JTextField drawRawGpsMaxLineLength = new JTextField(8);
private JCheckBox forceRawGpsLines = new JCheckBox(tr(Force lines if no
segments imported.));
private JCheckBox largeGpsPoints = new JCheckBox(tr(Draw large GPS
points.));
@@ -53,30 +57,49 @@
panel.setBorder(BorderFactory.createEmptyBorder(5,5,5,5));
// drawRawGpsLines
- drawRawGpsLines.addActionListener(new ActionListener(){
+ gpsLinesGroup = new ButtonGroup();
+ gpsLinesGroup.add(drawRawGpsLinesNone);
+ gpsLinesGroup.add(drawRawGpsLinesLocal);
+ gpsLinesGroup.add(drawRawGpsLinesAll);
+
+
Re: [josm-dev] [PATCH] Allow line drawing for local GPX files only
Jonathan Bennett wrote: The method used in this patch is based on the origin of the data, not what it happens to be named at the time. It's far more robust. ...plus it's better usability. With my patch, the user can see that this functionality is possible, explicitly. The other method requires them to figure out that it's possible, and the several steps needed to achieve the same thing -- not everyone using JOSM is a techie. J. -- Jonathan (Jonobennett) ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] OSM Fixer [Sequal]
2009/3/25 Stefan de Konink ste...@konink.de: Matt Amos wrote: yeah, the wiki page could probably do with some updating. but you remember this thread last month, right? http://lists.openstreetmap.org/pipermail/dev/2009-February/014024.html the issue with things referencing deleted items should go away because the transactions wrap the used-by checks. True; But isn't Rails doing that now too? [I am talking about the main database] Never the less, I asked Dave if he checked in the MySQL database if the presented violators are in there or if this is a hypercube issue. I would like to have a reply to that, because then it might be an issue that should be addressed by more people. looks like it might be a planet generation issue. maybe take a look at the history for some of the items which are causing you problems? That is exactly the reason I want to know if it is currently in the main database or not. http://api.openstreetmap.org/api/0.5/way/4043588/history http://api.openstreetmap.org/api/0.5/node/292984561/history The issue is that the hypercube 'dump' contains the waynds on 4043588, 292984561. Grant, Tom, could any of you if specifically this relation still exist in the main database? Who needs SQL? http://api.openstreetmap.org/api/0.5/node/292984561/ways So yes. It is. The API's Way.to_xml_node method strips out invisible nodes that it reads. http://api.openstreetmap.org/api/0.5/way/4043588 -- no node The OldWay.to_xml_node history calls do not. http://api.openstreetmap.org/api/0.5/way/4043588/history -- node (despite way timestamp saved after node was deleted) The hypercube dumps probably work off the osmosis diffs which read the history tables, hence the node in there. The main planet dump reads the current tables but doesn't filter the invisible ones like the API does. Potlatch also doesn't try to filter deleted nodes, so it'll appear in Potlatch too (and be successfully resurected if you save the way). So in those cases you will find a reference to a deleted node that the main API doesn't appear to have. Obviously the current ways shouldn't contain invisible nodes... but they do... and that'll be most likely due to lack of transactions etc etc Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
Stefan de Konink wrote: So I collected all the 'problematic' things. I think by what you mention, it can be trivially fixed just by fetching all nodes and reinserting them again? s/nodes/ways ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GSoC Ideas
Hello all, My name is Paul Wicks and I am a Computer Science major at the University of Puget Sound and I am interested in taking part in the Google of Summer of Code for the OSM project. The idea in the list that seemed to appeal to me most was the creation of a Static Map API. I'd be very interested in implementing something of this nature and have a bit of a basic plan sketched out (note that some of this is mentioned in the ideas list and also discussed a bit previously here). 1. Receive Latitude and Longitude coordinates, along with zoom level information, and return a static image (probably start with something really simple like ppm and go from there). Once this was achieved, everything else can be built up. The rendering path for images would have to be investigated (although from what looking I have done it looks like maybe mapnik would be the way to go, although it was suggested earlier that perhaps it would be better to grab the image tiles from the OSM servers and stitch them together), as I am not too familiar with the internals of OSM, having only used it for street maps up until now. 2. Once the absolute basics were in place, work on making it more useful. Maintaining a local cache of static maps would be important, so that maps would only need to be rendered once (although maybe maps should expire, since the canonical OSM map could itself change). Work would need to be done to determine the best way/place to store this data, especially considering that this project would most likely be aimed at deployment on Google App Engine. The other important thing, as I see it, would be to graft a key authentication mechanism on top the api, to prevent abuse. This seems like something that someone might have already written for django, so that would be good to look into. If not, it shouldn't be too difficult to create something of the sort. 3. Once the first 2 items were done, it would be more or less open season on whatever features were thought to be most useful. Markers (various types, colors, capacities), Paths/lines/boxes/shapes (again, many of the same options), additional caching backends (might as well increase the number of places that can run it as much as possible and not get locked into app engine), more image formats (jpg, gif, png, svg, pdf), different map themes (allow the api call to specify the colors of various map features, would this be possible/desired? maybe just have a dark theme and a light theme, that would probably encompass most needs for this feature) Another important thing would be to build a basic test suite around the api, both for benchmarking purposes and to help ensure it's integrity as development progressed. In the ideas list, django was mentioned as a possible platform for this and I would agree, for much the same reasons: it is written in a popular language and platform, meaning more developers in the future; deployment should be fairly easy, especially on something like app engine. Another wild thought I had was to create some sort of application that uses/showcases OSM for the iPhone/Android/Pre. This seems to be a hot new place for development these days and it would be cool to have an app that showcases OSM on one of these new mobile platforms. Perhaps a basic maps applicaion that uses OSM (although it looks like a jailbreak iphone can use OSM in the official maps app http://brainoff.com/weblog/2007/10/19/1271 ) or maybe something more specific, something that shows the strength of the OSM project. I'll have to think about this one some more. If this is not the place for this discussion or I've made any large errors, please let me know. Thanks for your time. -Paul Wicks ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC Ideas
Paul Wicks wrote: Hello all, My name is Paul Wicks and I am a Computer Science major at the University of Puget Sound and I am interested in taking part in the Google of Summer of Code for the OSM project. The idea in the list that seemed to appeal to me most was the creation of a Static Map API. I'd be very interested in implementing something of this nature and have a bit of a basic plan sketched out (note that some of this is mentioned in the ideas list and also discussed a bit previously here). 1. Receive Latitude and Longitude coordinates, along with zoom level information, and return a static image (probably start with something really simple like ppm and go from there). Once this was achieved, everything else can be built up. The rendering path for images would have to be investigated (although from what looking I have done it looks like maybe mapnik would be the way to go, although it was suggested earlier that perhaps it would be better to grab the image tiles from the OSM servers and stitch them together), as I am not too familiar with the internals of OSM, having only used it for street maps up until now. Please read into the standard WMS protocol. Information can be found at: Official documentation: http://www.opengeospatial.org/standards/wms Mapnik's implementation of wms: http://mapnik.org/news/2006/apr/18/wms/ Mapnik could act as a wms server, but this would not be good for performance since all rendering would be done straight from the openstreetmap db on the fly. A better trick would be to implement a tile-layer in a wms image server, the image would then take the required tiles, sticht them together in the requested projection, cut the area that is requested and return that to the client. 2. Once the absolute basics were in place, work on making it more useful. Maintaining a local cache of static maps would be important, so that maps would only need to be rendered once (although maybe maps should expire, since the canonical OSM map could itself change). Work would need to be done to determine the best way/place to store this data, especially considering that this project would most likely be aimed at deployment on Google App Engine. The other important thing, as I see it, would be to graft a key authentication mechanism on top the api, to prevent abuse. This seems like something that someone might have already written for django, so that would be good to look into. If not, it shouldn't be too difficult to create something of the sort. Caching with WMS is something that, as far as I know is not common, If you can figure out a way of caching and write a proposal, please also offer it to the mentor group at www.osgeo.org, they would gladly help 3. Once the first 2 items were done, it would be more or less open season on whatever features were thought to be most useful. Markers (various types, colors, capacities), Paths/lines/boxes/shapes (again, many of the same options), additional caching backends (might as well increase the number of places that can run it as much as possible and not get locked into app engine), more image formats (jpg, gif, png, svg, pdf), different map themes (allow the api call to specify the colors of various map features, would this be possible/desired? maybe just have a dark theme and a light theme, that would probably encompass most needs for this feature) That is nothing new, it is merely a matter of adding layers in the wms request. Another important thing would be to build a basic test suite around the api, both for benchmarking purposes and to help ensure it's integrity as development progressed. Stick to the open protocol and your testing will also be defined. You can use a lot of free wms clients around for testing: uDig qGIS JOSM Merkaartor In the ideas list, django was mentioned as a possible platform for this and I would agree, for much the same reasons: it is written in a popular language and platform, meaning more developers in the future; deployment should be fairly easy, especially on something like app engine. Another wild thought I had was to create some sort of application that uses/showcases OSM for the iPhone/Android/Pre. This seems to be a hot new place for development these days and it would be cool to have an app that showcases OSM on one of these new mobile platforms. Perhaps a basic maps applicaion that uses OSM (although it looks like a jailbreak iphone can use OSM in the official maps app http://brainoff.com/weblog/2007/10/19/1271 ) or maybe something more specific, something that shows the strength of the OSM project. I'll have to think about this one some more. If this is not the place for this discussion or I've made any large errors, please let me know. Thanks for your time. -Paul Wicks
Re: [OSM-dev] GSoC Ideas
El Miércoles, 25 de Marzo de 2009, Milo van der Linden escribió: Mapnik could act as a wms server, but this would not be good for performance since all rendering would be done straight from the openstreetmap db on the fly. You're wrong - mapnik depends on a local PostgreSQL database, not on the OSM API. A better trick would be to implement a tile-layer in a wms image server, the image would then take the required tiles, sticht them together in the requested projection, cut the area that is requested and return that to the client. If you're going to do WMS, better to do it from vector data rather than from stitching and warping tiles together. You'll ensure better place naming and consistent widths. Caching with WMS is something that, as far as I know is not common, If you can figure out a way of caching and write a proposal, WMS caches tend to not be efficient, so they end up not helping much. You want cached maps? Then use tiles. Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es Más vale una paz relativa que una guerra ganada.- María Theresa. signature.asc Description: This is a digitally signed message part. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM Fixer [Sequal]
On Wed, Mar 25, 2009 at 7:06 PM, Stefan de Konink ste...@konink.de wrote: Matt Amos wrote: the issue with things referencing deleted items should go away because the transactions wrap the used-by checks. True; But isn't Rails doing that now too? [I am talking about the main database] no. the current mysql database uses a mixture of myisam and innodb tables which prevents us from (easily) adding transactions (or, indeed, foreign keys). the choice of myisam for some tables is presumably historical, although there might be some technical reasons too. if we were to convert all the tables to innodb we could add transactions, but this would mean significant API downtime. happy for us, then, that we're rolling out 0.6 Real Soon Now with all that transactional and FK goodness and a bunch of other cool stuff too! cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
