[Potlatch-dev] [OpenStreetMap] #4327: Potlatch 2 simple mode should let users choose multiple parking types
#4327: Potlatch 2 simple mode should let users choose multiple parking types +--- Reporter: Will Pittenger | Owner: potlatch-dev@… Type: defect | Status: new Priority: minor | Milestone: Component: potlatch2 | Version: Keywords: | +--- If a node or closed way is of type parking, PL2 should let users choose multiple values for the type. A single parking location could be surface '''and''' Park Ride. It doesn't make sense to force editors to choose between those values. -- Ticket URL: https://trac.openstreetmap.org/ticket/4327 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] [OSM-talk] Map key on osm.org
Hi. Preface: I'll copy this mail to the dev@openstreetmap.org list, too, so please restrict to one list when answering; but I think, this mail deals with dev-issues, too and parts of the discussion might progress better on dev. I don't see the English descriptions, so I hope to guess the right keys for you. Most issues I list here are missing or obsolete items. Errors (where the map key and the map differ) are marked as ERROR! if you only want to deal with these. German descriptions in paratheses. I checked everything up to zoom level 10, afterwards it's difficult as both, map and key get more crowded. So in higher zoom levels I restrict to errors and issues I see by accident. Btw: What about generating the map key from the stylesheet automatically? Is there any ongoing work on that? level 0: renders only land and water, but map key contains motorway (Autobahn), trunk (Schnellstraße) and Country? These are not shown up to level 4. borders (Landesgrenzen, sonstige Grenzen) level 1: similar to 0, borders are shown, the other two are obsolete in the map key level 2, 3: missing key for Country labels level 4: no differentiation between the two, but different border types (countries vs. states) level 5: missing key for Capitals level 6: glaciers are missing (but quite prominent e.g. in the Alps). Meaning of the city label changes (compared to lvl5): includes additional big cities. level 7: national parks are missing, but rendered (light green) level 8: map shows forests/woods (very prominent), but that's not in the map key level 9: missing key for agricultural landuse (Landwirtschaft in level 10), but prominent in many areas. Rivers missing level 10: Motorway key should contain the shield (as common in commercial maps), Airports are missing, restricted areas are missing (the red, diagonal striped areas) level 11: trunks and primary roads are rendered with shields in the map, should be reflected in the map key; motorway links are rendered as small numbers, but not in the map key. Peaks are missing in the map key; nature reserve(?) (rendered as small green NR icons on areas) is missing in the map key level 13: tertiary is missing in the map key well... on a deeper look the error I saw is no error (secondary and tertiary are similar, and I interpreted the secondary map key for a street that was a tertiary in the map, while in that area no secondary is present). Nevertheless: Anything that counts against generating the map key in general out of the stylesheet? If that would be possible, we could additionally support the opencyclemap, public transport map (afaik both rendered with mapnik, too) and probably even Mapquest, if they support this. Is there any development on http://svn.openstreetmap.org/applications/rendering/mapnik/legend.py ? Probably that is a good starting point for automatic generation of the map key? regards Peter Am 22.03.2012 14:42, schrieb Steve Chilton: I produced the images (ages ago). If there are anomalies in the colours or symbols please let me know as I can change them. They are deliberately a subset of all the possible entities that could be included. Cheers Steve Steve Chilton, Learning Support Fellow Educational Development Manager Centre for Learning and Teaching Enhancement Middlesex University phone: 020 8411 5355 email: ste...@mdx.ac.uk Profile: http://www.middlesex.wikispaces.net/user/view/steve8 Chair of the Society of Cartographers: http://www.soc.org.uk/ Chair of ICA Neocartography Commission: http://www.soc.org.uk/neocartography/ -Original Message- From: Tom Hughes [mailto:t...@compton.nu] Sent: 22 March 2012 13:37 To: Peter Wendorff Cc: t...@openstreetmap.org Subject: Re: [OSM-talk] Map key on osm.org On 22/03/12 13:23, Peter Wendorff wrote: How is the map key (german: Legende) generated on osm.org? It looks like it is out of sync for the mapnik rendering (viewing from Germany, description texts are in german). - some items are not matching between map key and map - many items rendered in the map are not reflected in the map key Has this e.g. to be generated for an updated mapnik stylesheet? It's completely manual - at some point somebody gave me a load of images and text and I build a key from them. Tom ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Directionality of lanes
Hello I have a question about official tags for the diretionality of lanes. You have left-hand traffic (LHT) in countries like Japan, Australia, England and RHT, right-hand traffic in other countries. The tag "lht_ref" seems to indicate it, but I am not sure which is the right value. There is an other tag "rht_ref" as well, so I am confused. Shouldn't it be a tag like: name: traffic_direction value: lht / rht / open The tag "direction" seems to be used for other purposes. With regards Dietrich ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Overpass Question
Hi lets go through the questions one by one. - which query-language is suited for what? I suggest using the Overpass QL syntax. This and the XML language both offer the same semantics, but Overpass QL is more concise. Overpass QL has been created because the XML language looks cumbersome to most people. - what's this .-x or .-_ about? Overpass has an imperative execution model. In particular, the staements are executed one after another, and each statement is terminated by a semicolon. Each statement puts its results into a container in its memory named by default _. If a statement needs input, it reads its input from _. For example, the print statement reads from _. Sometimes it is useful to use more than one container during a more complex query. In this case, the output can be redirected to another container, e.g. with name x. This is what the above syntax controls. - will a print-command print all results of all unions or only the last one? It prints the content of the container _ at execution time. This comes very close to the last one. - are two queries in a union get ANDed or ORed? They are ORed. I tried to fiddle an overpass-query together that would give me: - all relations tagged with type=boundary or type=multipolygon - their way-members - nodes used by thode way-members The query [timeout:86400]; ( rel[type=boundary]; rel[type=multipolygon]; ); ( ._; way(r); node(w); ); out; does that. but I was unable to get this result. I'd love to see a walktrgough or a tutorial that explains the building blocks and how they interact in a chronological order without adding stuff that isn't explained. Lets walk through the example: [timeout:86400]; is necessary in this case because we expect a really large result. The 86400 is an amount of time in seconds and means that we expect a runtime up to a whole day. The default value is 180 seconds, which fits well to the usual timeouts of browsers or other HTTP clients. rel[type=boundary]; collects all relations from the database that have a tag with key type and value boundary. The result is stored in the memory of the query server, in the container _, because this is the default behaviour. If you want to see what has happened so far, you can print the content of the container at this point: http://overpass-api.de/api/interpreter?data=rel[type=boundary];out; Similarly, rel[type=multipolygon]; collects all relations from the database that have a tag with key type and value multipolygon. Check the results with http://overpass-api.de/api/interpreter?data=rel[type=multipolygon];out; This is already quite a lot of data. Now, the union statement comes into effect. It takes a copy of each output and produces as result the union of each output. ( rel[type=boundary]; rel[type=multipolygon]; ); This means that here, first the output of rel[type=boundary]; is collected, then the output of rel[type=multipolygon]; is collected. The union of both is stored at the end of the statement into the container _ and replaced the content of container _ after the last substatement, rel[type=multipolygon]. To see the conent of the container _ at this point, run http://overpass-api.de/api/interpreter?data=(rel[type=boundary];rel[type=multipolygon];);out; On a semantic level, we now have in the container _ all relations that are of type boundary or of type multipolygon. We now get to the second union block: ( ._; way(r); node(w); ); The first substatement, ._, is only useful in a union block: It has as output in the container _ the input from container _. While this doesn't change container _, it lets union copy the current content of container _ to its own output. Thus, we have now all relations of the interesting type in both the container _ and the union's internal container. The next substatement, way(r); reads its input from the container _ and writes its output again to the container _, replacing the input data. Thus, on a semantic level, way(r); puts all ways that are members of a relation of interesting type into the container _. Because it is a substatement of union, this unoin block adds this output to its internal storage. The next statement, node(w); again reads its input from the container _ and writes its output to the container _. It finds all nodes that are members of the ways in its input. Because container _ contains at this point of time all ways that are members of a relation of interesting type into the container _, we now have exactly the nodes that we want in the container _. And because we are still in the union block, the internal union storage now contains the relations (from ._), the ways (from way(r);), and the nodes (from node(w);) that we want. At the end of the union statement, in the source code at );, the statement puts this into the cotainer _. In a final step, we only need to print this, adding an out; statement. If you want meta information, you may
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
Hi Parveen, Sorry for the delay in replying, I had missed this email. I like the idea of making it easy for less technical users to create their own maps. You are right that it is now (relatively) easy to set up a tile server given the work that has been done packaging the main tools, but creating a map style is quite a task, and even customising the default OSM one is daunting. Therefore I think a project based on helping people create custom map styles is a good thing. To turn your idea into a good proposal, I think you need to address the following: - How will this work - is it a text file that the user edits manually, or will there be a graphical interface? - If it is a graphical system, is it a desktop application or a web based one? In either case, how will you go about it? - Will it work on mapnik XML style sheets, or carto CSS ones.or maybe the CSS style used by KothicJS and others? - It would be good to compare your ideas to TileMill, which is going a long way to doing what you are proposing, but I think we lack a tilemill (carto) base style for OSM data to customise (I have some very simple ones, but they are way off the complexity of the standard OSM mapnik style). One of last year's Mapnik GSoC projects may have created an XML to carto converter, which could help? Therefore one possibility may be to use tilemill as a base for the project. The simplest step forward, which I think would be useful would be to extend the use of entities in the existing XML stylesheet so that all of the styles for drawing the various components are defined in a single place, separated from the more complicated bits, but I have not looked at how feasible this is given the support for various zoom levels in the style sheet - it may not be much simpler (but could maybe have a file for each zoom level?). Anyway, these are just a few thoughts to help you put together a proposal which you would like to work on, and are confident in being able to achieve in the GSoC timescale. Regards Graham. On 25 March 2012 13:06, Parveen Arora m...@parveenarora.in wrote: Hi All, I want to apply for OSM GSoC. I am having idea of StyleSheet Generator for OSM, i.e. users can create style-sheets of their own choice based upon their own preferences and requirements and those stylesheets can be used using any renderer. Using this maps for Map for visually handicapped can be created easily, the one who can't read small fonts or are having color blindness, so that maps suitable for them can be easily available. This can have many more benefits like any one who wants to show particular roads or points on the map can generate the style-sheets for that. One more thing is that there is lot of work already has been done to set up map tile server that one can easily do that using few commands, and that can be more useful applied with stylesheet generator. Please let me know If something similar already exist so that I can check that and can look for improvements in that if required. If there is nothing exist similar, this can be feasible during the GSoC time period. Please give your valuable suggestions, feedback and improvements or anything else that can be done along with this idea. Thank You. -- Parveen Arora www.parveenarora.in E-Mail: m...@parveenarora.in ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Graham Jones Hartlepool, UK. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
I want to apply for OSM GSoC.
I am having idea of StyleSheet Generator for OSM, i.e. users can
create style-sheets of their own choice based upon their own
preferences and requirements and those stylesheets can be used using
any renderer.
Please let me know If something similar already exist so that I can
check that and can look for improvements in that if required
Something similar exists.
http://wiki.openstreetmap.org/wiki/Komap
It is mapcss-to-mapnik and mapcss-to-kothicjs stylesheet converter. The idea
behind it is to have a single stylesheet that can be used in JOSM, Potlatch,
Mapnik, Kothic and a bunch of other renderers.
There are a lot of improvements that can be done to it:
- reformat all hacks to some real mapcss structures, i.e. invent a nice
syntax for dem coloring, hillshading parameters, layering model.
- add at east some support for cascading for non-cascaded renderers like
mapnik (i.e. allow structures like:
way{color: black; font-face: Arial}
way[highway]{casing-width:1; color: red}
way[highway=primary]{width:3; text:name}
)
- add more rendering backends, from popular demand - maperitive, geoserver;
probably also some mobile apps like osmand / gpsmid;
- some more crazy ideas? integrate it with some renderer (kothic js?
maperitive?) and make a easy map generator software, with simple buttons
edit stylesheet, publish for web, make tiles, make pdf for printing,
make svg for further editing.
Komяpa, OSM BY Team
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Directionality of lanes
Hi! a) please do not use HTML mail on the list b) there are no official tags in OSM c) do not tag directionality of highways. it would add millions of tags to OSM with no use because it is obvious what the right value is for each country You can see here http://taginfo.openstreetmap.org/keys/lht_ref that lht_ref is used only once and not documented, rht_ref a bit more often, but also undocumented. Both are only used in the US. Whatever lht_ref/rht_ref is, it doesn't seem to be what you are looking for. Jochen On Tue, Mar 27, 2012 at 09:35:37AM +0200, Dietrich Opitz wrote: Date: Tue, 27 Mar 2012 09:35:37 +0200 From: Dietrich Opitz d.op...@salondigital.de To: dev@openstreetmap.org Subject: [OSM-dev] Directionality of lanes html head meta http-equiv=content-type content=text/html; charset=ISO-8859-15 /head body bgcolor=#FF text=#00 br Hellobr br I have a question about official tags for the diretionality of lanes.br br You have left-hand traffic (LHT) in countries like Japan, Australia, Englandbr and RHT, right-hand traffic in other countries.br br The tag lht_ref seems to indicate it, but I am not sure which is the right value.br There is an other tag rht_ref as well, so I am confused.br br Shouldn't it be a tag like:br br name: traffic_direction br value: lht / rht / openbr br The tag direction seems to be used for other purposes.br br br With regardsbr br Dietrichbr br /body /html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Directionality of lanes
On Tue, Mar 27, 2012 at 11:19 AM, Jochen Topf joc...@remote.org wrote: This thread shouldn't continue on the dev-mailing-list... c) do not tag directionality of highways. it would add millions of tags to OSM with no use because it is obvious what the right value is for each country The wiki has a proposal to describe default values per country in a 'default' relation type: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults But since directionality of lanes is never changing (although Samoa did it in 2009), I could imagine that navigation softwares can hardcode the value for each country. Pieren ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Directionality of lanes
Hello Thank you for the information. I didn't wanted to add the obivous to the database. I just missed the default settings per country and was wondering how to get this type of information from the database. Thank you --- Dietrich Am 27.03.2012 12:09, schrieb Hartmut Holzgraefe: On 03/27/2012 11:50 AM, Pieren wrote: But since directionality of lanes is never changing (although Samoa did it in 2009), Sweden did it somewhere in the 1970s ... but yes, it is a very rare event and when it happens it is easier to change the country default in one place than to re-tag every single highway object in that country ... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
Here are 30 min make your own OSM map with TileMill instructions by AJ Ashton that points to a quite comprehensive OSM style sheet. http://mapbox.com/blog/create-a-custom-map-of-your-city-in-30-minutes-with-tilemill-and-openstreetmap/ I've made this map with it using a geofabrik download: http://tiles.mapbox.com/lxbarth/map/OSMBrightBosnia On Mar 27, 2012, at 4:12 AM, Graham Jones wrote: Hi Parveen, Sorry for the delay in replying, I had missed this email. I like the idea of making it easy for less technical users to create their own maps. You are right that it is now (relatively) easy to set up a tile server given the work that has been done packaging the main tools, but creating a map style is quite a task, and even customising the default OSM one is daunting. Therefore I think a project based on helping people create custom map styles is a good thing. To turn your idea into a good proposal, I think you need to address the following: • How will this work - is it a text file that the user edits manually, or will there be a graphical interface? • If it is a graphical system, is it a desktop application or a web based one? In either case, how will you go about it? • Will it work on mapnik XML style sheets, or carto CSS ones.or maybe the CSS style used by KothicJS and others? • It would be good to compare your ideas to TileMill, which is going a long way to doing what you are proposing, but I think we lack a tilemill (carto) base style for OSM data to customise (I have some very simple ones, but they are way off the complexity of the standard OSM mapnik style). One of last year's Mapnik GSoC projects may have created an XML to carto converter, which could help? Therefore one possibility may be to use tilemill as a base for the project. The simplest step forward, which I think would be useful would be to extend the use of entities in the existing XML stylesheet so that all of the styles for drawing the various components are defined in a single place, separated from the more complicated bits, but I have not looked at how feasible this is given the support for various zoom levels in the style sheet - it may not be much simpler (but could maybe have a file for each zoom level?). Anyway, these are just a few thoughts to help you put together a proposal which you would like to work on, and are confident in being able to achieve in the GSoC timescale. Regards Graham. On 25 March 2012 13:06, Parveen Arora m...@parveenarora.in wrote: Hi All, I want to apply for OSM GSoC. I am having idea of StyleSheet Generator for OSM, i.e. users can create style-sheets of their own choice based upon their own preferences and requirements and those stylesheets can be used using any renderer. Using this maps for Map for visually handicapped can be created easily, the one who can't read small fonts or are having color blindness, so that maps suitable for them can be easily available. This can have many more benefits like any one who wants to show particular roads or points on the map can generate the style-sheets for that. One more thing is that there is lot of work already has been done to set up map tile server that one can easily do that using few commands, and that can be more useful applied with stylesheet generator. Please let me know If something similar already exist so that I can check that and can look for improvements in that if required. If there is nothing exist similar, this can be feasible during the GSoC time period. Please give your valuable suggestions, feedback and improvements or anything else that can be done along with this idea. Thank You. -- Parveen Arora www.parveenarora.in E-Mail: m...@parveenarora.in ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Graham Jones Hartlepool, UK. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev Alex Barth http://twitter.com/lxbarth tel (202) 250-3633 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
On Tue, Mar 27, 2012 at 1:42 PM, Graham Jones grahamjones...@gmail.com wrote: Hi Parveen, I like the idea of making it easy for less technical users to create their own maps. You are right that it is now (relatively) easy to set up a tile server given the work that has been done packaging the main tools, but creating a map style is quite a task, and even customising the default OSM one is daunting. Therefore I think a project based on helping people create custom map styles is a good thing. Thanks To turn your idea into a good proposal, I think you need to address the following: How will this work - is it a text file that the user edits manually, or will there be a graphical interface? Yeah for sure, providing easy UI will be its first preference. If it is a graphical system, is it a desktop application or a web based one? I will prefer to make it web based, to make it System Independent. I have worked on a project of university following the same concepts to generate files with PHP In either case, how will you go about it? Will it work on mapnik XML style sheets, or carto CSS ones.or maybe the CSS style used by KothicJS and others? If we take entries from users into database, then we can generate any type of file from database. XML or CSS by fetching all the variable values from the database. It would be good to compare your ideas to TileMill, which is going a long way to doing what you are proposing, but I think we lack a tilemill (carto) base style for OSM data to customise (I have some very simple ones, but they are way off the complexity of the standard OSM mapnik style). One of last year's Mapnik GSoC projects may have created an XML to carto converter, which could help? Yeah I am checking that. Therefore one possibility may be to use tilemill as a base for the project. Is it mean to do improvements in tilemil? The simplest step forward, which I think would be useful would be to extend the use of entities in the existing XML stylesheet so that all of the styles for drawing the various components are defined in a single place, separated from the more complicated bits, but I have not looked at how feasible this is given the support for various zoom levels in the style sheet - it may not be much simpler (but could maybe have a file for each zoom level?). Not got this point, Can you please elaborate it a bit more? Anyway, these are just a few thoughts to help you put together a proposal which you would like to work on, and are confident in being able to achieve in the GSoC timescale. Thank You very much for replying back and for suggestions :) -- Parveen Arora www.parveenarora.in E-Mail: m...@parveenarora.in ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Schema for v0.6 OSM files?
I'm wondering, does anybody have an up-to-date XML Schema or DTD for the OSM files used by the v0.6 API? The ones I found at http://wiki.openstreetmap.org/wiki/API_v0.6/XSD and http://wiki.openstreetmap.org/wiki/API_v0.6/DTD don't seem to fully represent the format. For example, using xmllint to validate a downloaded relation gives the following result: $ wget http://www.openstreetmap.org/api/0.6/relation/65559 $ xmllint --noout --schema osm0.6.xsd 65559 65559:3: element relation: Schemas validity error : Element 'relation', attribute 'uid': The attribute 'uid' is not allowed. 65559 fails to validate $ xmllint --noout --dtdvalid osm0.6.dtd 65559 65559:3: element relation: validity error : No declaration for attribute version of element relation 65559:3: element relation: validity error : No declaration for attribute uid of element relation Document 65559 does not validate against osm0.6.dtd Note, the DTD and XML Schema even seem to disagree with each other as to whether relations may have a version attribute. Regards, Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Schema for v0.6 OSM files?
On 27/03/12 16:53, Robert Helgesson wrote: I'm wondering, does anybody have an up-to-date XML Schema or DTD for the OSM files used by the v0.6 API? The ones I found at http://wiki.openstreetmap.org/wiki/API_v0.6/XSD and http://wiki.openstreetmap.org/wiki/API_v0.6/DTD don't seem to fully represent the format. Those are both user contributed and quite likely permanently out of date as none of the developers will be likely to update them. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] CT-incompatible planet file?
Is there anywhere a CT-incompatible planet file? i.e a file containing all the ways and nodes which are likely to be dropped during the rebuild. I'd like to understand which islands are going to disappear, and I'm thinking that if there were such a file, and I passed this through the coastline error checker files, the resulting shapefiles would be a help David ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] CT-incompatible planet file?
-Original Message- From: David Groom [mailto:revi...@pacific-rim.net] Sent: Tuesday, March 27, 2012 1:33 PM To: dev@openstreetmap.org Subject: [OSM-dev] CT-incompatible planet file? Is there anywhere a CT-incompatible planet file? i.e a file containing all the ways and nodes which are likely to be dropped during the rebuild. I'd like to understand which islands are going to disappear, and I'm thinking that if there were such a file, and I passed this through the coastline error checker files, the resulting shapefiles would be a help David I've been thinking and I think what the best way to do this is to generate it based on ways that are dropped or ways that have all or all but one of their nodes dropped. These are ways that are going to be completely removed. Every other way will exist as at least a two-node way in the clean DB and will be picked up by coastcheck. It shouldn't be too hard for me to write the logic for that, but I'll need to find the time. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] CT-incompatible planet file?
- Original Message - From: Paul Norman penor...@mac.com To: 'David Groom' revi...@pacific-rim.net; dev@openstreetmap.org Sent: Tuesday, March 27, 2012 10:32 PM Subject: RE: [OSM-dev] CT-incompatible planet file? -Original Message- From: David Groom [mailto:revi...@pacific-rim.net] Sent: Tuesday, March 27, 2012 1:33 PM To: dev@openstreetmap.org Subject: [OSM-dev] CT-incompatible planet file? Is there anywhere a CT-incompatible planet file? i.e a file containing all the ways and nodes which are likely to be dropped during the rebuild. I'd like to understand which islands are going to disappear, and I'm thinking that if there were such a file, and I passed this through the coastline error checker files, the resulting shapefiles would be a help David I've been thinking and I think what the best way to do this is to generate it based on ways that are dropped or ways that have all or all but one of their nodes dropped. These are ways that are going to be completely removed. Every other way will exist as at least a two-node way in the clean DB and will be picked up by coastcheck. It shouldn't be too hard for me to write the logic for that, but I'll need to find the time. Ok ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
On Tue, Mar 27, 2012 at 2:10 PM, Darafei Praliaskouski m...@komzpa.net wrote:
Hi Darafei,
Something similar exists.
http://wiki.openstreetmap.org/wiki/Komap
Nice to see that.
It is mapcss-to-mapnik and mapcss-to-kothicjs stylesheet converter. The idea
behind it is to have a single stylesheet that can be used in JOSM, Potlatch,
Mapnik, Kothic and a bunch of other renderers.
There are a lot of improvements that can be done to it:
Yeah, Its also written on their project page, that it is not available
for daily use.
- reformat all hacks to some real mapcss structures, i.e. invent a nice
syntax for dem coloring, hillshading parameters, layering model.
Is it mean that should I go for rebuilding it with following all the
coding standards and concept?
- add at east some support for cascading for non-cascaded renderers like
mapnik (i.e. allow structures like:
way{color: black; font-face: Arial}
way[highway]{casing-width:1; color: red}
way[highway=primary]{width:3; text:name}
)
- add more rendering backends, from popular demand - maperitive, geoserver;
probably also some mobile apps like osmand / gpsmid;
- some more crazy ideas? integrate it with some renderer (kothic js?
maperitive?) and make a easy map generator software, with simple buttons
edit stylesheet, publish for web, make tiles, make pdf for printing,
make svg for further editing.
That seems a nice job, but if we have to generate tiles it should be
some desktop application preferably, because I have tried to generate
tiles through web browsers and faces lot of security issues in that.
Thank You for suggestions :)
--
Parveen Arora
www.parveenarora.in
E-Mail: m...@parveenarora.in
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
In either case, how will you go about it? Will it work on mapnik XML style sheets, or carto CSS ones.or maybe the CSS style used by KothicJS and others? If we take entries from users into database, then we can generate any type of file from database. XML or CSS by fetching all the variable values from the database. I am not sure where the database idea comes into it - the xml style file is very complicated - are you proposing to include all the parts of that in a database to re-generate it? Kompza also mentioned a tool to convert between style types, which would be worth looking at. Therefore one possibility may be to use tilemill as a base for the project. Is it mean to do improvements in tilemil? I haven't really thought about it, but thought that if you want a graphical style editor, tilemill does a lot of that, so you might be able to build on it rather than start from scratch. The simplest step forward, which I think would be useful would be to extend the use of entities in the existing XML stylesheet so that all of the styles for drawing the various components are defined in a single place, separated from the more complicated bits, but I have not looked at how feasible this is given the support for various zoom levels in the style sheet - it may not be much simpler (but could maybe have a file for each zoom level?). Not got this point, Can you please elaborate it a bit more? I think it is a bit simple for what you have in mind, but XML allows you to define entities (~=named constants as far as I can tell). Look at the main OSM style - there is an inc/entities.xml.inc file that defines quite a lot. I was wondering about parameterising it so we have a single '.inc' file that defines the road widths, casing widths, colours etc. in a simpler looking file. Again, I have not looked at how much simpler this would make it, because it may be complicated by the number of different zoom levels. I guess you could do it for colours very easily, but road widths could be harder. Once you have got all of the information that a casual user is likely to want to modify in a single, simpler looking file, it would be less daunting for a non-technical user to update it. There is not a lot of 'code' in this idea though, so it may not be a good GSoC project on its own, unless it were linked to something else to make it easier for users to make their own maps. -- Graham Jones Hartlepool, UK. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
On Wed, Mar 28, 2012 at 10:20 AM, Graham Jones grahamjones...@gmail.com wrote: I am not sure where the database idea comes into it - the xml style file is very complicated - are you proposing to include all the parts of that in a database to re-generate it? As I thought, to take values from the user of their choice and then to move all that values to a database. and then we can generate any type of file from that. As I have looked into the style file of osm.xml, it looks like a easy pattern followed in it. Kompza also mentioned a tool to convert between style types, which would be worth looking at. Yeah I have checked it, A similar idea. I think it is a bit simple for what you have in mind, but XML allows you to define entities (~=named constants as far as I can tell). Look at the main OSM style - there is an inc/entities.xml.inc file that defines quite a lot. Got it, Thanks. There is not a lot of 'code' in this idea though, so it may not be a good GSoC project on its own, unless it were linked to something else to make it easier for users to make their own maps. okay, So I think I should look at some other idea from Ideas list as the time is very less to submit early proposal. Thank You. -- Parveen Arora www.parveenarora.in E-Mail: m...@parveenarora.in ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
Sorry parveen I have confused you. The thing that is probably too simple for a gsoc project is my last point about converting the style file to use entities. The idea of a graphical style editor is fine. Graham from my phone On 28 Mar 2012 06:13, Parveen Arora m...@parveenarora.in wrote: On Wed, Mar 28, 2012 at 10:20 AM, Graham Jones grahamjones...@gmail.com wrote: I am not sure whe... As I thought, to take values from the user of their choice and then to move all that values to a database. and then we can generate any type of file from that. As I have looked into the style file of osm.xml, it looks like a easy pattern followed in it. Kompza also mentioned a tool to convert between style types, which would be worth looking at Yeah I have checked it, A similar idea. I think it is a bit simple for what you have in mind, but XML allows you to define entities (~... Got it, Thanks. There is not a lot of 'code' in this idea though, so it may not be a good GSoC project on its o... okay, So I think I should look at some other idea from Ideas list as the time is very less to submit early proposal. Thank You. -- Parveen Arora www.parveenarora.in E-Mail: m...@parveenarora.in ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] StyleSheet Generator for OSM [GSoC'12]
On Wed, Mar 28, 2012 at 10:46 AM, Graham Jones grahamjones...@gmail.com wrote: Sorry parveen I have confused you. Its ok, I have got your point. The thing that is probably too simple for a gsoc project is my last point about converting the style file to use entities. Yeah, It will be easy one. The idea of a graphical style editor is fine. Thanks, But I have thought to work on some other idea because there is already similar works done in Komap (Kothic MapCSS processor.) So I am want to propose some potential and feasible idea. If graphical style editor can be one, I will be happy to work on that. Thank You. -- Parveen Arora www.parveenarora.in E-Mail: m...@parveenarora.in ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
