Re: [OSM-talk] How INSPIRE data are sold in your countries

[nebulon42]

In Austria we have a lot of open data (mostly CC-BY) like:
* aerial imagery with pixel resolution of ~ 30cm
* digital basemap
* DEM out of ALS data with 10m distance
* address data
and various other data sets. For OpenStreetMap it was possible to get an
exception or modification from the attribution clause.

But there are also products that are pricy. Example: DEM with 5m
distance ~ 170.000 Euro for all of Austria, licensed by the Federal
Office of Metrology and Surveying. But I really don't know much about
license costs of other datasets. I'm sure that they exist.

nebulon42

Am 2018-05-02 um 17:07 schrieb Honza Cibulka:
> Hello,
> 
> I am in the middle of court proceedings related to prices which Czech
> state GIS authority asks for INSPIRE data (for context, it´s about
> hundreds of thousands Euro for altimetry dataset, which is basically off
> reach for anyone).
> 
>  
> 
> I want to know what is common practice among other EU countries, how
> your governments are setting prices of state-created GIS data, and how
> restrictive licensing terms are (our license basically forbids use of
> state data to create OSM).
> 
>  
> 
> Of course I know that British Ordnance Survey maps are free for
> download, but I need more examples, preferable from countries with legal
> systems similar to us, like Slovakia, Germany, Austria, Hungary, Poland,
> Spain and others...
> 
>  
> 
> Thanks for all info you could send me.
> 
>  
> 
> Jan Cibulka
> 
> tel.: +420 776 307 158
> 
> datastory.cz <https://datastory.cz/>
> 
>  
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] landcover=grass requires area=yes to render in Mapnik carto

[nebulon42]

As far as I'm aware the landcover key is currently not rendered at all
on the standard layer. Do you have an example? How does it render if you
add area=yes?

Normally area=yes is only required to tell osm2pgsql that some closed
way which is tagged in a way that it is treated as linestring should be
treated as polygon instead.

Michael

Am 2017-06-03 um 20:28 schrieb Dave F:
> Hi
> 
> On the 'standard' rendering landcover=grass tags (haven't test any
> others, it might be all) requires area=yes to render.
> 
> Anybody aware of the reason landcover has to have this?
> 
> DaveF
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Upcoming removal of landuse=farm in the standard style

[nebulon42]

Dear all,

at openstreetmap-carto - the standard style on osm.org - a change has
been merged
(https://github.com/gravitystorm/openstreetmap-carto/pull/2554) to drop
rendering of landuse=farm. There was overall consensus that this tag is
deprecated and its usage steadily declined over the last years, but
there are still around 340 000 uses. See
https://taginfo.openstreetmap.org/tags/landuse=farm and
http://taghistory.raifer.tech/ for details.

This change will make it into the next release, but there is no release
date yet. You might want to change cases of landuse=farm in your area to
either landuse=farmland or landuse=farmyard before that. Please don't do
any automatic re-tagging though. After the release empty spots will make
it easier to clean up the remaining uses of this tag.

Michael



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Overpass API v0.7.54 version

[nebulon42]

Great! I already like the first new feature you wrote about. With it
it's now possible to query Overpass API for old style multipolygons (at
least those that have no other tags on the relation than type):

relation({{bbox}})
  [type=multipolygon]
  (if:count_tags()==1);
(._;>;);
out;

Thanks a lot!

Michael

Am 2017-03-08 um 05:26 schrieb Roland Olbricht:
> Dear all,
> 
> a new version of Overpass API is now available. It has already been
> rolled out on a the production server.
> 
> There are release notes on the releases page in the wiki:
> http://wiki.openstreetmap.org/wiki/Overpass_API/versions
> 
> As the new features are quite a lot, I will present them over the next
> weeks in a dedicated blog:
> http://dev.overpass-api.de/blog/
> 
> Best regards,
> 
> Roland
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[nebulon42]

Are your continuous claims of FUD more FUD?
Or is me questioning this more FUD of FUD of FUD?

You see this can go on towards infinity.

Am 2017-01-04 um 22:01 schrieb Andy Mabbett:
> On 4 January 2017 at 19:49, Frederik Ramm  wrote:
> 
>> there's quite a few people in OSM who think that
>> low-quality Wikidata tags are better than no Wikidata tags at all
> 
> Are there? Or is this more FUD?
> 
>> we can afford to wait until someone who actually knows the area they are
>> working in has the time to add Wikidata tags.
> 
> As has been made clear in other discussions in which you have been
> involved, this is already underway.
> 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[nebulon42]

I would revert it then.
Violations of the automated edits policy should not be tolerated.

Michael

Am 2017-01-04 um 19:17 schrieb Philip Barnes:
> On Wed, 2017-01-04 at 18:16 +0200, Tomas Straupis wrote:
>> There was a flow of undiscussed automated wikidata additions in
>> Lithuania with problems. I asked for discussion before automated
>> changes. I was given a promise that a discussion will follow. But
>> there was no discussion. And automated changes resumed. I see it as
>> violation of automated edit rules and would like these edits to stop.
>> Anybody can do atomated changes, it does not take too much knowledge
>> or inteligence to do them. We will do it ourselves, when we want it.
>> So stop!
> 
> That also happened in the UK, the community were promised time to
> review the proposed imports for our areas but it happened before we had
> a chance to comment.
> 
> Phil (trigpoint)
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] addr:interpolation and data consumers

[nebulon42]

Hi,

I have written an address QA script for Austrian addresses. Now I'm
asked to support addr:interpolation. While the script is specific to
Austria the more general problem of addr:interpolation is not.

In my opinion addr:interpolation is of little value for data consumers.
Personally, I prefer addresses on nodes or buildings where the location
of the address is clear. addr:interpolation rather leaves this open. I
know that addr:interpolation is an established tag, but the Wiki also says:

"As long as we don't have a node or building outline for each
house(number) along a way, it's also possible to use automatic number
interpolation."
(https://wiki.openstreetmap.org/wiki/Addresses#Using_interpolation)

For me that sounds like: use it until there is something better/more
accurate. I tend to replace addr:interpolation with addresses on nodes
or buildings when I see them and more accurate data is available.

What is the opinion on addr:interpolation here?

For reference: https://github.com/gmgeo/at-address-compare/pull/1

(not on tagging to reach a more diverse audience)

nebulon42



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Taglists support for rendering examples

[nebulon42]

I have to strongly disagree with "have been written in the right way",
"correct", "incorrect", "problem", "should be fixed".

Both notations are correct and I have deliberately chosen the latter
one. The first one may be the right one for the problem you are trying
to solve. For the problems I wanted to solve the latter one was the
right one.

The problem of sizes should be solved by the downstream application or
the icons should be changed in the Wiki, not in the osm-carto repository.

Michael

Am 2016-11-06 um 12:52 schrieb Jochen Topf:
> Hi!
> 
> I have now added support to taginfo for showing an example rendering in
> the taglists on the wiki.
> 
> If the "osmcarto-rendering" field in the KeyDescription or
> ValueDescription info box template is set to an image link (typically
> something like "Image:foo.svg" or "File:foo.svg"), this image will
> show up in taglists if the taglists have the "with_rendering=true"
> parameter. 
> 
> A detailed explanation is at:
> https://wiki.openstreetmap.org/wiki/Taginfo/Taglists
> 
> Note that the "osmcarto-rendering-size" setting in the infobox is not used.
> That setting is really not neccesary if the icons have been written in
> the right way. If you look into the SVG of the icons you'll see the
> difference:
> 
> The correct SVG looks something like this:
> 
> 
> The incorrect SVG looks something like this:
> 
> 
> So you have to explicitly set the right size. This is a common problem
> with many icons and they should be fixed in the original repository at
> https://github.com/gravitystorm/openstreetmap-carto and then re-imported
> into the Wiki.
> 
> (And yes, it would make sense if we didn't have to copy the images into
> the wiki, but there are more issues with that. I am trying to do the
> next step here, not change everything in one go.)
> 
> With this change the taglists can be made to look exactly like the old,
> manually created ones (for instance on the MapFeatures page).
> 
> Jochen
> 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM New Logo Proposal

[nebulon42]

Like it. As the current trends in graphic design go it fits right in.
Less clutter, flat, clear. Colours are nice, but would probably need
more discussion. A specific font for the word OpenStreetMap also makes
sense in terms of CI considerations.

I cannot comment on whether OSM needs a new logo or not. But it does not
hurt to refresh it.

Michael

Am 2016-10-14 um 16:36 schrieb Elio Qoshi:
> Hi there,
> 
> Elio here, Designer and Open Source contributor from Albania.
> 
> Based on the new Donation Initiative Logo, I thought it would be a good
> time to discuss around adapting a new logo which is more suitable for
> print, smaller displays and generally a broader variety of backgrounds.
> 
> Having this in mind, I came up with a proposal of a logo, including the
> wordmark, which was never included as part of it. The wordmark is
> written in "Overpass" an Open Source font sponsored by Red Hat. Overpass
> is based on the street sign font, so I think it's a perfect fit:
> 
> http://cloud.elioqoshi.me/index.php/s/QjdOYc7WyoSBFqv/download
> 
> What do you think of it? I believe it's time to suggest a new more
> modern logo for OSM nowadays to make it more usable for communities to
> adapt it.
> 
> I look forward to your feedback!
> 
> P.S: Also posted an issue on GitHub:
> https://github.com/openstreetmap/openstreetmap-website/issues/1326
> 
> Cheers,
> 
> -- 
> Elio Qoshi
> 
> FLOSS Designer at Ura Design
> Mozilla Tech Speaker
> Fedora Ambassador
> T:  @elioqoshi
> W:  elioqoshi.me / ura.design
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto release v2.44.1

[nebulon42]

Yes, look at https://www.openstreetmap.org/#map=9/42.1430/0.9407. You
might need to clear your cache though.

Am 2016-10-12 um 20:25 schrieb Marcos Oliveira:
> Does this fix spanish villages/towns that have admin_level=* and
> capital=* tags from being rendered as cities?
> 
> 2016-10-12 19:20 GMT+01:00 Marcos Oliveira
> mailto:marcosoliveira.2...@gmail.com>>:
> 
> Does this fix spanish villages/towns that have admin_level=* and
> capital=* tags from being rendered as cities?
> 
> 2016-10-12 19:02 GMT+01:00 Paul Norman  >:
> 
> Dear all,
> 
> Today, v2.44.1 of the openstreetmap-carto stylesheet (the default
> stylesheet on openstreetmap.org ) has
> been released. Also, v2.44.0 was
> released last month without an email, so this email includes changes
> in both.
> 
> v2.44.0 has been rolled out to the openstreetmap.org
>  servers, but v2.44.1
> has not yet.
> 
> Major changes are
> - Rendering of restricted access roads and paths significantly
> changed
> - Changed to use Noto fonts for all languages
> 
> Other changes in both versions include
> - A code of conduct adopted, based on the Go code of conduct
> - Adjustments to city wall rendering
> - Revised low zoom place rendering
> - Render both house name and number if address has both
> 
> Thanks to all the contributors for this release, in particular Lukas
> Sommer, Hsiao-Ting Yu and vholten for work in debugging complex font
> issues with the Noto CJK fonts.
> 
> For a full list of commits from both releases, see
> 
> https://github.com/gravitystorm/openstreetmap-carto/compare/v2.43.0...v2.44.1
> 
> 
> 
> As always, we welcome any bug reports at
> https://github.com/gravitystorm/openstreetmap-carto/issues
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> 
> 
> 
> -- 
> Um Abraço,
> Marcos Oliveira
> 
> 
> 
> 
> -- 
> Um Abraço,
> Marcos Oliveira
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Upload slowness - what's going on?

[nebulon42]

As said before: great explanation and great work. These are complicated
tasks, so thanks to the whole OWG for managing all this.

nebulon42



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Change in line barrier rendering coming up

[nebulon42]

With the next update of openstreetmap-carto the line barrier catch-all 
rendering is going to be removed. That means that no longer every value 
of barrier=* is rendered on the standard layer but only the most used 
(consolidated) values. For a list of tags and details see 
https://github.com/gravitystorm/openstreetmap-carto/pull/1986.


This change (in the same way as other catch-all removals some time ago) 
is intended to improve tagging quality and reduce tagging for the 
renderer. The particular list is of course open to continuous 
discussion. As concrete example barrier=line is going to be removed from 
the rendering, which is in my opinion clearly a case of tagging for the 
renderer. Personally, I'm not opposed to mapping of sports field 
markings (the maintainers of osm-carto may have other opinions). Maybe a 
better tagging scheme can be devised for that.


nebulon42

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Improved new Icon set for Open Street map

[nebulon42]

Please tell us about which style you are talking or post a link so that 
we can have a look for ourselves. As far as the OSM standard style is 
concerned it does not have an icon for university buildings (yet).


nebulon42

Am 2015-11-03 um 07:28 schrieb Nasir Khan:

Thanks for the response.

The point i want to mention that, we should improve the Icons for
different type for establishments. For example "University Building" it
uses the "Home" icon, but i think it should be different because
building could be administration or hostel. This is an example but there
are other similar cases.


--
*Nasir Khan Saikat*
www.nasirkhn.com <http://www.nasirkhn.com>


On 3 November 2015 at 03:14, Andy Townsend mailto:ajt1...@gmail.com>> wrote:

On 02/11/2015 16:53, Nasir Khan wrote:

...

One thing i faced every time and asked from many that, is there a
way to improve the icon set to make the map more attractive.


(apologies if I'm stating the obvious here, but...)

"OpenStreetMap" isn't just "the standard map that you see at
openstreetmap.org <http://openstreetmap.org>".  There are five
different tile layers available from the layer switcher there,
designed for different purposes. Elsewhere, there are other styles.
For example,


https://github.com/search?utf8=%E2%9C%93&q=project+extension%3Amml&type=Code&ref=searchresults

currently finds > 700, and no doubt there are lots of others
elsewhere.  Depending on what data you're showing, I'd expect that a
different map style would make sense.  Just today I was using a
commercial application that showed locations using "MQ Open" tiles
(they wanted a road-atlassy thing I guess); something that wanted to
show location in a mountainous area I'd would expect show contours
or hillshading.  OpenStreetMap's "standard" style has as one of its
goals feedback to mappers, so it includes more detail (for example
of different sorts of shops) than I'd expect most general purpose
maps to want to show.

It's very possible (and not terribly difficult) to come up with a
map style that highlights the data that you want - making it then
look nice is the tricky bit, as to me would be figuring out how to
host and serve the data to allcomers (though as Wikimedia I suspect
you've solved that last bit).

Cheers,

Andy (SomeoneElse)



___
talk mailing list
talk@openstreetmap.org <mailto:talk@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Improved new Icon set for Open Street map

[nebulon42]

Hi,

the icons of osm-carto have been refreshed since December 2014. I'm not 
sure if you have noticed that a lot of icons of the Standard map style 
have changed (improved in my view) since that time. Me and others have 
already invested tons of hours into re-designing icons, reducing 
complexity and updating the visual style.


However, there is of course always the possibility to improve things 
further. I'm welcoming contributions at https://github.com/gmgeo/osmic, 
which is a repository that holds all icons I have done for the Standard 
map style (some I have also adapted from Maki and other free sources). 
You can also directly contribute to osm-carto at 
https://github.com/gravitystorm/openstreetmap-carto.


nebulon42

Am 2015-11-02 um 17:53 schrieb Nasir Khan:

Hi,

I am a big fan of Open Street Map. I used this for may of my web
application projects.

One thing i faced every time and asked from many that, is there a way to
improve the icon set to make the map more attractive. I really feel that
we all should look at this issue and make a plan to improve this user
experience. If you compare the OSM with the Google map icons, then you
can say that the Google Map is way more ahead that the OSM.

I am not sure if it is right forum to discuss this issue. Please help me
if i posted in the wrong mailing list. Any one can tell me if it is
already in the roadmap or not? If it is not, then i think we can start
the discussion right away. We can team up with some other platforms like
The Noun Project (https://thenounproject.com/) or some one else or do
something else.

thanks
Nasir Khan

--
*Nasir Khan Saikat*
www.nasirkhn.com <http://www.nasirkhn.com>
​Public Lead,
Creative Commons Bangladesh
Founding Member
Wikimedia Bangladesh​




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map key

[nebulon42]

Is this ACTUALLY a 'done deal'? I though there was a going to be at
least some option to ask if there was a more general agreement for the
change.


I cannot really comment on that as I'm not a maintainer of osm-carto. As 
far as the code is concerned the change has been merged into the style 
and there have been pull requests for adjustments already.


My personal opinion: I know that this change has not been received well 
by everybody. All concerns should be (and are) taken seriously and as 
much of feedback as possible is a good thing. There is always the 
possibility to add changes or improvements (e.g. 
https://github.com/gravitystorm/openstreetmap-carto/pull/1861). However, 
I also think that this change overall is a great improvement to the map 
and that design by committee does not work well. At the same time, 
seeing a greater diversity of (open) styles becoming available is a good 
thing and very much welcome.


nebulon42

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map key

[nebulon42]

There are some discussions already going on about this topic:
https://github.com/gravitystorm/openstreetmap-carto/issues/1268

There is this wiki page:
http://wiki.openstreetmap.org/wiki/Standard_tile_layer

Ultimately, an automatic solution would be preferable:
e.g. https://github.com/gravitystorm/mapnik-legendary

As for adjusting the map key right now, please note that there is a 
major roads redesign coming up, so I would suggest waiting until that 
has been rolled out to avoid duplicating effort. I don't know an ETA of 
this change on the tile servers yet as it is a quite major change. 
Others may be able to comment on that.


nebulon42

Am 2015-10-16 um 23:03 schrieb Andrew Hain:

I am having a look at the map key for the standard layer and I am finding a
number of loose ends.

One obvious issue is that the key is sometimes out of date: for instance it
distinguishes between forest and wood but the style sheet no longer does so.

The key talks about trunk, primary and secondary roads but this is just OSM
database keywords left exposed; these words have local meanings in some
countries that OSM differs from. It might be better to have an entry for
main roads using as many colours as are displayed at the zoom level in a
single row, which among other things saves space on mobile devices.

We also have an opportunity to add some more entries for further features
and to sort important stuff to the top.

--
Andrew


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Osmic icons for JOSM

[nebulon42]

I have created a style for JOSM that substitutes default POI icons with 
icons from Osmic. The style uses most of the 149 currently available 
icons from Osmic and re-uses the colour scheme used by osm.org's default 
style openstreetmap-carto. What I'm trying to achieve is more visual 
consistency between the individual POI icons.


I'm also trying to increase familiarity between JOSM's style and OSM's 
default map style, which might be helpful when editing. Since 
openstreetmap-carto also uses many of Osmic's icons making the 
connection between POI features on the slippy map and in the editor 
should be easier.


The project repository: https://github.com/gmgeo/osmic-josm-style

More details: https://www.openstreetmap.org/user/nebulon42/diary/35857

Your feedback is welcome.

nebulon42

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Best base to build on ...

[nebulon42]

I'm not sure how TileMill fits within your rendering stack here. Do you 
mean Mapnik?


If you talk about carto-based style development the best alternative for 
TileMill right now is Kosmtik (https://github.com/kosmtik/kosmtik), 
which is developed and maintained by Yohan Boniface. Some if not all of 
the maintainers of osm-carto use it. I have also switched from TileMill 
to Kosmtik for my work on osm-carto a few months ago. It is addressing 
the more tech-savvy kind of style developers (more command-line stuff), 
but the switch has also optimized my workflow.


Best, nebulon42

Am 2015-08-15 um 17:14 schrieb Lester Caine:

Not getting much help on the GB list so I thought I'd widen the
question. A couple of years back I had my own server setup working with
a base of OSRM and routing covering the UK. While the map server is
still working, routing has packed up and some of the alternate base maps
are no longer accessible.

Given that the OSM styling is going to switch to something which in my
book is unacceptable I needed to sort my own rendering as a base for UK
usages. I've got tilemill running finally with a few niggles, but I've
actually managed to switch some style elements to be more UK frindly
using darker road colours. But as yet I've not got the routing side
working again.

The obvious question is that given tilemill is not longer being
maintained, what are the preferred alternatives?  I'm actually not happy
with the way OSRM has moved and there does not seem to be a 'standard'
for the support structure? Each section seems to need a different set of
tool versions. I'm happy to have to use postgresql despite having had
two corruptions already, but mysql has no place here. My main stack is
Nginx, PHP and Firebird and I have tilemill running on top of that, and
the planet file is being replicated nicely.

So do I spend a lot more time on tilemill, or am I better switching
before spending too much more time on that, and what other options are
available to replace OSRM. OSMAND is working well for me in the car so
is that perhaps a better use of time given that I still have a time
hungry support service to provide ... and I still need OHM as an option ...

I need to get this machine configured before shipping over to the data
centre where it will sit on a high speed pipe so I need to get it right.



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD name suggestion index - asking non-English-speaking mappers to review

[nebulon42]

Another thing. Is this still active? There hasn't been much activity 
lately and it has also open pull requests that could have been merged 
already. I'm just asking because I spotted some things to correct, but I 
want to make sure that I do not waste my time because a pull request 
might not get merged.


Still, quite useful project!

nebulon42

Am 2015-05-16 um 20:07 schrieb Michał Brzozowski:

https://github.com/osmlab/name-suggestion-index

So this index is used in iD and it's supposed to suggest names of
shops/amenities that are part of some chain. (like: McDonald's, Aldi,
...). But due to how it works (counting occurrences) there are generic
nouns that end up here, which is bad tagging (like shop=bakery
name=Bakery [1]) and could form a feedback loop that proliferates them
even more.

I ask non-English speakers to find anything they are sure it's a noun
and not a proper name. name-suggestions.json specifies name
suggestions and filter.json specifies what "non-names" should be
filtered.

Some examples I found that need confirmation:

Аптека
Apotheke
Boulangerie
Пекарня
Зоомагазин
Обувь
Стройматериалы
Салон красоты


[1] For the sake of example, as "Bakery" is filtered already

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD name suggestion index - asking non-English-speaking mappers to review

[nebulon42]

Apotheke is the German noun for pharmacy.
Best, nebulon42

Am 2015-05-16 um 20:07 schrieb Michał Brzozowski:

https://github.com/osmlab/name-suggestion-index

So this index is used in iD and it's supposed to suggest names of
shops/amenities that are part of some chain. (like: McDonald's, Aldi,
...). But due to how it works (counting occurrences) there are generic
nouns that end up here, which is bad tagging (like shop=bakery
name=Bakery [1]) and could form a feedback loop that proliferates them
even more.

I ask non-English speakers to find anything they are sure it's a noun
and not a proper name. name-suggestions.json specifies name
suggestions and filter.json specifies what "non-names" should be
filtered.

Some examples I found that need confirmation:

Аптека
Apotheke
Boulangerie
Пекарня
Зоомагазин
Обувь
Стройматериалы
Салон красоты


[1] For the sake of example, as "Bakery" is filtered already

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wiki project: Article about the standard layer, with key

[nebulon42]

Great work so far! I will update icons (if necessary) when new releases 
go live.


Best, nebulon42

Am 2015-04-22 um 14:58 schrieb Wuzzy:

Thanks for the icons, I have included most of them in the article
now. :-)

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wiki project: Article about the standard layer, with key

[nebulon42]

Great! I can offer some support regarding the symbols that have been 
redrawn by me.


Why bother with PNG when we can have SVG versions? I will upload all of 
my icons that are currently used by osm-carto in coloured SVG versions 
to the wiki and collect them at this page: 
http://wiki.openstreetmap.org/wiki/User:Nebulon42/Icons


(By the way it is easy to create a coloured Osmic icon collection like 
that by looking at 
https://github.com/nebulon42/osmic/blob/master/tools/export.md.)


I will also replace any existing new symbols in your key page with these 
SVG versions. As I'm not able to replace all other usages of the new 
symbols (maybe not needed yet?) I could use some help with that.


Best, nebulon42

Am 2015-04-20 um 14:27 schrieb Wuzzy:

I have created a wiki page about the Standard layer found on
www.openstreetmap.org


Here it is:
https://wiki.openstreetmap.org/wiki/Standard_tile_layer

This wiki page is still a big work in progress.

Here are two goals of this wiki page:
1) Concentrate on user's view, not mapper's view
2) Give a brief description of the Standard layer and other information
of intererest.
3) Document all the map colors, symbols and lines. Also known as “key”.

I know that the homepage has already a key, but it is very incomplete
and outdated, most symbols (“points of interest”) are not explained at
all.

Does anyone want to help with this effort?

There are the following challenges:
- I want to have the pure, unaltered icons in their original size. Many
   icons I found in the wiki are pretty outdated.
- If possible, the icons should be stored as uniform as possible in the
   wiki. It looks ugly if all the icons are displayed in different sizes
- Documenting all the non-obvious stuff about the layer, such as that
   private access things are drawn semi-transparent, etc.
- Keeping this whole thing up to date

You can help by:
- Extending the key
- Give advice if you know more about the inner workings of the Standard
   layer
- Uploading missing icons into the wiki
- Updating outdated icons in the wiki
- Adding more general information about this layer




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Osmic (OSM Icons) 0.1

[nebulon42]

Hi,

I'm happy to announce the availability of the first release 0.1 of Osmic 
(OSM Icons). Osmic is a collection of 100+ clean high quality SVG icons 
optimised for small sizes. The icons are licensed under Public Domain 
(or CC0).


The Github Repository: https://github.com/nebulon42/osmic

For further details have a look at this diary entry: 
http://www.openstreetmap.org/user/nebulon42/diary/34709


Best, nebulon42

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New Mapfeatures (Views) on openstreetmap.org: Proposal for additional

[nebulon42]

Hi,

while you're at it..regarding the Transport Map I have no idea why it 
does not show railway routes. This would also be a possbile improvement.


But I'm afraid it is a bit complicated. As I read elsewhere these maps 
are included from third party servers. For example, the bike and 
transport maps were made by Andy Allan (opencyclemap.org, 
thunderforest.com) so you should probably talk to him.


Best, nebulon42

Am 22.01.14 23:55, schrieb A. Jacubowsky:

Hello all,

I have taken a look into the new Map features and found some points
which could make the maps more useful for Users.

So I would like to start a discussion which elements are needed to be
shown in the different Map views.

Proposed improvements for the „Bicycle Map“:

Show also parking places (many Bicycle tours are start from and/or end here)

Show also waterways also if “landuse=residential”

Show waterways more visible (especially streams are shown extreamly
small, but a canal which is only 0,5 meters width is shown much better)

Show wastebaskets (Vending machine for excremental of Dogs and benches)

Show

Show important Sightseeing places

With the above changes, the Bicycle Map can also use as „Walking Map“
(the overlap is very large), so we would have a “Walking and Bicycle Map”

Proposed improvements for the „Transportation Map“:

Display also parking places (especially P+R parking should be shown
prominent)

regards

Alexander Jacubowsky

Milcheshohl 27, 61462 Königstein
E-Mail: a...@jacubowsky.info <mailto:a...@jacubowsky.info>

Fon   : +49 (6174) 20 16 34

Fax   : +49 (6174) 20 16 84

Mobil : +49 (179) 50 70 90 9

-->> This Mail was checked by eleven (www.eleven.de) using x-purgate
relay. Please contact Jacubowsky EDV (i...@ajedv.de) for more
information. <<--


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk