geotag location in work
priyolahiri opened this issue · 53 comments
every work should have an optional lat, lng. this would give me a map of areas worked, and also ties in experience duration with locations which can help companies offer jobs by location relevance and comfort factor with the location.
example:
work: [{
company: string, // e.g. Facebook
position: string, // e.g. Software Engineer
website: string, // e.g. http://facebook.com
startDate: string, // resume.json uses the ISO 8601 date standard e.g. 2014-06-29
endDate: string, // e.g. 2012-06-29
summary: string, // Give an overview of your responsibilities at the company
highlights: [ // Specify multiple accomplishments
string // e.g. Increased profits by 20% from 2011-2012 through viral advertising
],
"location": {"lat":45.243434, "lng": 23.43243242}
}]
I'd also like to include lat/lng in a persons current location.
Interesting, will make it much easier for analysis
Geo-coordinates are very important for understanding resumes, especially when it comes to machine comprehension (Where is this individual based? Where have they worked? Where do they desire to work? etc.) I'd love to see this feature. 👍
...themes could also incorporate maps, etc.
👍 to geotagging
I would suggest rather then creating a generic object {lat,lng} for a location, that the location be a valid geoJSON object. This will simplify the mapping of this data by falling back on an existing spec.
More information can be found here: http://geojson.org/geojson-spec.html
+1 for geoJSON. At the very least it should be an acceptable format for template parsers when they see a "location" field.
So either
"location": {"lat": 45.243434, "lng": 23.43243242 }
or
"location": { "type": "Point", "coordinates": [45.243434, 23.43243242] }
?
I would say "location": {"lat": 45.243434, "lng": 23.43243242 } instead of geoJson as very few "enterprises" have gotten to working with geoJSON as a tech, but everybody has used google apis and thus can directly take the lat, lng and pass it in to get an inference of location. Also, the other reason that I would say that geoJSON will not be much use because most of geoJSON's variety of geometry like bounding boxes, straight lines, etc. would never be used and this would always come in the form of lat and lng point. So why add the overhead of geoJSON? Someone who parses this json can also get a geoJSON point object from the lat and lng if they work with geoJSON. Also why add the overhead of the extra bytes, when half the specs of geoJSON would never be used in this case? -1 for geoJSON.
I wouldn't mind an optional "lat" and "lng" in the location block. But the main info should be human readable as far as I'm concerned. Especially since we're reusing the same location keyword.
For example, patching bio.location it would look like:
"location": {
"city": "San Francisco",
"countryCode": "US",
"state": "California",
"lat": 123.456,
"lng": 123.456,
},
As for adding the location to the work object. Is that the only place we'd like that added to? Or perhaps in education too? And possibly in a bunch more of the newly suggested objects (e.g. volunteerWork)?
Acceptance criteria for closing this issue is that this is well documented. Some users will likely drop off here.
Users will need to know, "How can I find out the geolocation of my company (or university)?"
Hhmmmm after thinking some more on this, I wonder if we're actually doing the work of the tool in the jsonresume ecosystem by providing lat,long values. If a user chooses to specify a city or even a more specific address, it's up to the template system/cli/... to query GMaps for instance, to get the geolocation.
Technically, geo-information is secondary information in the context of a resume. It can be "calculated" from the location information.
As long as the field is not mandatory, I don't see a problem with including it. It provides tremendous value for any non-human trying to make sense of the resume, or for generators who want to include a map or similar.
Geocoding is not trivial. In Norway, we don't have "states", as the spec allows. We have "fylker" (counties) and "kommuner" (municipalities). Some of these municipalities even have the same names. Lots of towns have the same names. Trying to geocode "Dale, Norway" or "Vik, Norway" is just not sufficient to find the right one.
Specifying a lat/lng does however allow the reverse to happen; using reverse geocoding, a resume generator/presenter would be able to display "Dale, Fjaler, Sogn og Fjordane, Norway", or simply "Dale, Norway" with a link to open a map on the right spot.
And if I may ask, how do you come by those geo coordinates? Surely whatever tool is parsing the jsonresume can use the same data you use, to get proper coordinates. Your example just tells me that you did not provide enough information for GMaps to get the right coordinates.
Since this is my own resume, knowing where to look for Dale, Norway on a map is not a problem. For a parser, that's much harder.
By all means, if we can provide additional fields to narrow down the location (so geocoders can have an easier time) - fine, but while "county" and "municipality" might make sense for Norway, something else might make sense for Uzbekistan or India. Instead of defining the fields, perhaps it would be better to provide an array of different levels: ["Dale", "Fjaler", "Sogn og Fjordane", "Norway"] - then again, this would be mostly useful for a geocoder, presenting it to a human without knowing what they represent is slightly harder.
I still don't see why a lat/lng combination shouldn't be an optional field.
But you don't live in "Dale, Norway", but more specifically in a city/municipality within "Dale, Norway". So if you put "Norway" in country, "Dale" in region and "Fjaler"/"Sogn og Fjordane" in city, isn't that specific enough for GMaps to find the right city?
edit: When I put "Dale, Norway, Fjaler" in GMaps, it give back 1 result.
You've got region/city the wrong way around, but yes, region is a pretty broad term, so one could say:
{
"city": "Dale",
"countryCode": "no",
"region": "Fjaler, Sogn og Fjordane"
}Which works fine for defining where I live. It doesn't necessarily work if I want to define a place that I've worked (if I want it to be more fine-grained than the city). That would require the geocoder to know where the business is located, which OSM/GMaps doesn't necessarily know.
I just think you're losing a whole lot of flexibility when not defining the lat/lng coordinates. If I want to present my resume on my website, I'd have to write a step that transforms all the points I want to map to lat/lng coordinates first, or have a whole bunch of javascript client-side which connects to a geocoding API etc. I'd love to just be able to transform a JSON-schema into a beautiful resume with everything I need in a few lines of client-side javascript.
We obviously disagree on this issue, so I'll let my opinion be noted, and leave it at that :-)
It's not a dealbreaker for me, but somehow it feels "wrong" to include geo coordinates, because it's semantically not part of a resume.
We'll let others chime in on this issue :)
@dandydev Agree. It should not be mandatory in any case and only an optional addition to the location fields we already have. Probably we don't even need it at all.
If we added it as a required field, editing or creating the JSON resume could not be possible anymore without additional tools.
I don't think anyone means geo coordinates to be mandatory. It was optional from the outset. But I'm advocating leaving it out altogether :)
Having co-ordinates in the json will also allow companies to find people in a radius of let's say 500 kms without parsing it first. Isn't that reason enough?
@priyolahiri That's a reason to add it as an optional field, yes.
Valid point! But is it necessary to add it to each work entry for that? Why not just add it (optionally) to the location section (of the user him/herself)?
As a potential employer I'm most interested in where they live, not where they worked. Sure, you can try and determine if potential employees are willing to travel, but I think it's much more interesting to know where they actually live (geo-wise) and decide if I want to be travel costs for such a distance, and if such a distance is even acceptable for me as an employer.
I think geo-coordinates were meant to be optional from the beginning.
@dandydev For a big service company, they would certainly be interested to know where you've worked if they want to know what are the likely locations that you would like to be deployed at for client sites. Again, I am talking large IT/ITES service companies, not individual and small and medium businesses.
@dandydev Agree that this is only useful in the location section that is about yourself. I don't think potential employers should judge your flexibility by analyzing geodata from your past positions.
@priyolahiri I don't think big IT companies will go as far. And regardless, I don't think we should support this on work-entry level. For the location section it's useful.
28 comments in, my impression is that this is an optional nice-to-have, therefore -1 for this feature at this time.
@priyolahiri wrote:
"Having co-ordinates in the json will also allow companies to find people in a radius of let's say 500 kms without parsing it first. Isn't that reason enough?"
No. Companies are interested in hiring the right talent and relocating that talent from around the world. Also, resume writers are the primary audience rather than companies.
Q: How easy/difficult is it to defer this decision for a future version so we can get this in front of eyes quickly?
It takes a lot of time to relocate talent from around the world. Ursula,
you might want to do some research on how things are doing in big IT
industries. You might even try researching IBM and internal allocation.
People have family and commitments. Location plays an extremely big part
specially in senior levels.
On 12-Jul-2014 12:34 am, "Ursula Kallio" notifications@github.com wrote:
28 comments in, my impression is that this is an optional nice-to-have,
therefore -1 for this feature at this time.@priyolahiri https://github.com/priyolahiri wrote:
"Having co-ordinates in the json will also allow companies to find people
in a radius of let's say 500 kms without parsing it first. Isn't that
reason enough?"No. Companies are interested in hiring the right talent and relocating
that talent from around the world. Also, resume writers are the primary
audience rather than companies.Q: How easy/difficult is it to defer this decision for a future version so
we can get this in front of eyes quickly?—
Reply to this email directly or view it on GitHub
#12 (comment)
.
'as far' - can you explain?
On 11-Jul-2014 7:01 pm, "Daan Debie" notifications@github.com wrote:
@priyolahiri https://github.com/priyolahiri I don't think big IT
companies will go as far. And regardless, I don't think we should support
this on work-entry level. For the location section it's useful.—
Reply to this email directly or view it on GitHub
#12 (comment)
.
Ursula, you might want to do some research on how things are doing in big IT industries. You might even try researching IBM and internal allocation.
Sounds a bit condescending to me :)
On-topic: your argument is still irrelevant. As @opensourcegrrrl mentioned, resume writers are the primary audience. If a company really wants to target people from a certain area, they can either manually look for resume's from people for that area (as they're doing now) or they can automate it without having the geo coordinates. GMaps is your friend in that.
-1 to include geo coordinates for now. Let's close this issue and optionally come back to it at a later time if we get a lot of requests for that.
Please vote.
@priyolahiri Fear not, I spent 8-some years in the Valley.
@dandydev Thanks for the backup. 'ppreciate it.
-1
Ursula spoke with so much authority and finality on the matter, I could not help it.
Maybe this well help to explain: http://dspace.mit.edu/handle/1721.1/28686
I have a feeling that everyone is looking at this project more from a job seeker perspective but there’s a lot less deep dive on how enterprise works and how resource allocation happens. I am talking companies with workforce of > 100000
And the valley isn’t the world.
On 12-Jul-2014, at 12:51 am, Daan Debie notifications@github.com wrote:
Ursula, you might want to do some research on how things are doing in big IT industries. You might even try researching IBM and internal allocation.
Sounds a bit condescending to me :)
On-topic: your argument is still irrelevant. As @opensourcegrrrl mentioned, resume writers are the primary audience. If a company really want to target people from a certain area, they can either manually look for resume's from people for that area (as they're doing now) or they can automate it without having the geo coordinates. GMaps is your friend in that.
-1 to include geo coordinates for now. Let's close this issue and optionally come back to it at a later time if we get a lot of requests for that.
Please vote.
—
Reply to this email directly or view it on GitHub.
I see two primary audiences for this project: job seekers and prospective employers
Prospective employers may also want to start using this format for maintaining internal employee data to ensure uniformity across internal and external resource pools. I don’t think we are doing enough on that.
I feel we need to cover and think of all bases before we do a +1 or a -1.
You can make it super-friendly for the job seeker, and choose to make things hard and convoluted and time consuming for the employer. But I don’t see large scale adoption in that case. Look at http://www.hropenstandards.org/ to understand depth and scope.
Being great for startups and small and medium businesses solves a small part of the bigger problem.
On 12-Jul-2014, at 8:22 am, Priyadarshi Lahiri admin@priyolahiri.in wrote:
Ursula spoke with so much authority and finality on the matter, I could not help it.
Maybe this well help to explain: http://dspace.mit.edu/handle/1721.1/28686
I have a feeling that everyone is looking at this project more from a job seeker perspective but there’s a lot less deep dive on how enterprise works and how resource allocation happens. I am talking companies with workforce of > 100000
And the valley isn’t the world.
On 12-Jul-2014, at 12:51 am, Daan Debie notifications@github.com wrote:
Ursula, you might want to do some research on how things are doing in big IT industries. You might even try researching IBM and internal allocation.
Sounds a bit condescending to me :)
On-topic: your argument is still irrelevant. As @opensourcegrrrl mentioned, resume writers are the primary audience. If a company really want to target people from a certain area, they can either manually look for resume's from people for that area (as they're doing now) or they can automate it without having the geo coordinates. GMaps is your friend in that.
-1 to include geo coordinates for now. Let's close this issue and optionally come back to it at a later time if we get a lot of requests for that.
Please vote.
—
Reply to this email directly or view it on GitHub.
Prospective employers may also want to start using this format for maintaining internal employee data to ensure uniformity across internal and external resource pools. I don’t think we are doing enough on that.
You can make it super-friendly for the job seeker, and choose to make things hard and convoluted and time consuming for the employer. But I don’t see large scale adoption in that case.
Assumptions.
Supporting this will make it a lot more convoluted for job-seekers, which for now, is the main target audience.
We already said that we will get to this at a later time. For the first draft it was proposed to leave geo-coordinates out and come back to it if and when we get a lot of requests. I'm gonna make an assumption as well: companies with workforces > 100000 are probably using LinkedIn for their searches, which has perfectly applicable tooling for that, and they will keep using that for detailed applicant searches anyways.
Also:
Being great for startups and small and medium businesses solves a small part of the bigger problem.
Maybe this exposes the real problem: we haven't defined properly what problem we're trying to solve yet :)
The voting right now is for what is going through in the first official release and other ideas will be revisited as the project matures. (This should be added to the documentation, I've created an issue at #94).
We've had a few smaller companies reach out and express interest in using JsonResume as an import/export format. Realistically this will be the only way the project gains traction, so we aren't too concerned about trying to cater towards corporate and large scale business for now.
Back onto the topic at hand, I won't be doing any development for the lat/long property because it affects every module in the ecosystem. There are other higher priorities development-wise so I would rather explore the topic more at a later day.
Because of the tension in the thread, I'm going to close the issue and have already added it as a link in the README. We will re-open it in the near future, once we have pushed out some of the other core changes.
And as in any good open source project, personal attacks will not be tolerated.
I definitely agree with having lat/lon within location, and I think @wdoekes example is probably the easiest and best way to implement it.
On second thought, I've been doing some work around geolocation and such, and there's a few standards that can work:
"location": {
"lat": 41.12,
"lon": -71.34
}
"location": "41.12,-71.34"
"location": [ -71.34, 41.12 ]
I like the last one, it's fairly easy to use and implement, makes sense and doesn't need 2 properties, just one. However, I'm not sure what to name the property itself. 'geo', 'geolocation', 'latlon'?
@mboudreau I think we should avoid to use an abbreviation. Do you have any source for a standard about geotag?
Also, if we can avoid the use of adresses I would love it. Addresses are jokes. Sincerely.
I agree latitude and longitude should be first class citizens, but try sending documents to a GPS location... Not going to get delivered most of the time. So address should still be another first class citizen.
Back to the suggestions. I like the last approach, but on a second thought having the specific fields named reduces the mental work people/devs have to do, when interacting with the standard. That shouldn't be the sole focus, but needs to be considered.
I think we should follow the Point schema of GeoJson:
{
"coordinates": [125.6, 10.1]
}It is @mboudreau last suggestion.
@stp-ip I agree, address is still very important for me.
I did consider the mental work needed, but the fact is, the geo location normally needs to be fed into a function or API, which often times uses this format. For example, I'm currently trying to index JSON Resume into ElasticSearch and they accept a document with the geolocation format in an array format.
I don't think the mental work is a big factor since very rarely will the dev ever need to access just one, or print off both. It's normally something that's just fed into a map or into another system like google maps, which has an API that interacts like this:
https://maps.googleapis.com/maps/api/geocode/json?latlng=40.714224,-73.961452
Which using the format I've suggested, is a simple join if you're doing strings:
var url = "https://maps.googleapis.com/maps/api/geocode/json?latlng=" + resume.basics.location.coordinates.join(',');
Or, if you're using an HTTP library, most of them has a place for params:
var request = require('https');
request({
url: "https://maps.googleapis.com/maps/api/geocode/json",
params: {
latlng: resume.basics.location.coordinates.join(',')
}
});
Thanks for addressing my concern. I agree and see that it might be not as bad as previously thought. Especially considering, that we might add more tooling around the standard, which might help theme devs etc. to use specific formats.
Proposal:
Add lat/long as coordinatesfollowing the Point schema of GeoJson. to work, school, etc.
{
"coordinates": [125.6, 10.1]
}
@stp-ip I think I agree with you ;)
+1
Ok final decission for implementation for now.
- add coordinates as optional field for all location items.
- make address optional
- add documentation about latlon and address issues
{
"coordinates": [125.6, 10.1]
}
Could it be an idea to use Google's plus codes when defining the address? It'll simplify the schema; and cover any address types worldwide.
https://github.com/google/open-location-code/
HI folks, just taking a looksy, I like the idea of this project
After much thought, I don't think this schema request is useful for the larger use case.
Although the ability to analyse/report on resume data is ideal, most people merely want to display their location.
The Google open-location-code sounds like the best way forward in the future though.